Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 136500

Article: 136500
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Nov 2008 06:42:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 6:25=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> Hallo.
>
> When using a Spartan3 SliceM in 2x SRL16-Mode,
> the Slice-FlipFlops and the SRLs must share the same clock
> (and from the FPGA-Editor, it looks like if that clock's
> polarity must be the same for both, SRLs and FFs).
>
> Now, if I want to use the FFs (I don't think they can be
> used for anything else then buffering the SRL's Output),
> I'm not fully sure the FF clk will be early enough
> to not sample the SRL during undefined output.
>

Very unlikely.  The SRL clock to output time is longer than
a fabric flip-flop and the clock routing within a slice is very
fast.

> I think it's very likely that the FF clk is early enough,
> but I don't see a way to ask the xilinx tools about that
> (apart from the module attached compiles without errors
> in ISE10.1 web).
>

You could run a timing simulation after place & route.

> Has anyone tried a simulation about this?
>
> Gruss
>
> Jan Bruns
>
> module shiftreg16F(di,o,clk,cke,cke2,a);
> =A0 input di;
> =A0 output o;
> =A0 input clk;
> =A0 input cke;
> =A0 input cke2;
> =A0 input [3:0] a;
> =A0 reg [15:0] shiftdata;
> =A0 reg tmp;
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] <=3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] <=3D di;
> =A0 =A0 end
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp <=3D shiftdata[a];
> =A0 =A0 end
> =A0 end
> =A0 assign o =3D tmp;
> // synthesis attribute RLOC of shiftdata[15:0] is "X0Y0"
> // synthesis attribute RLOC of tmp is "X0Y0"
> // synthesis attribute BEL of shiftdata[15:0] is "F"
> // synthesis attribute BEL of tmp is "FFX"
> endmodule


Article: 136501
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Nov 2008 06:44:59 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 8:49=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Jan Bruns":
>
> > I think it's very likely that the FF clk is early enough,
> > but I don't see a way to ask the xilinx tools about that
> > (apart from the module attached compiles without errors
> > in ISE10.1 web).
> > =A0always @(posedge clk)
> > =A0begin
> > =A0 =A0if (cke) begin
> > =A0 =A0 =A0shiftdata[15:1] <=3D shiftdata[14:0];
> > =A0 =A0 =A0shiftdata[0] <=3D di;
> > =A0 =A0end
> > =A0 =A0if (cke2) begin =A0
> > =A0 =A0 =A0tmp <=3D shiftdata[a];
> > =A0 =A0end
> > =A0end
>
> The following also compiles without error:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 end
>
> but the opposite blocking behaviour compiles, but infers flipflops
> instead of srl16:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 end
>

Am I missing something or did you paste the same code
here twice?  Is this the code that caused XST to infer
flip-flops?

> I didn't notice that xst now has better blocking assignment support
> (or maybe I got a false impression about older xst versions when
> learning verilog).
>
> Gruss
>
> Jan Bruns


Article: 136502
Subject: Re: vga interfacing for image display
From: ales.gorkic@gmail.com
Date: Wed, 19 Nov 2008 07:00:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 8:33 am, deep <infoparaj...@gmail.com> wrote:
> hello,
>         i am currently working on the spartan 3a dsp 1800a development
> board.i am trying to interface the vga port for displaying image
> stored in the memory(may be BRAM or distributed).in the vga port there
> are 2 timing signals vsync and hsync and 3 color signals for RGB.i can
> display 8 colors from the 3 bit combinations RGB but the image we have
> stored in the memory has more than 8 color combinations,so anybody who
> is working on the vga interfacing section can share their
> view........., thank you.

As I recall the S3A DSP board has 12bit (4bit per colour) VGA output
producing 4096 colours. Try Genode FX distribution for GUI which
includes also the support for S3A DSP board. Very powerful stuff.

Cheers,

Ales

Article: 136503
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 19 Nov 2008 16:07:44 +0100
Links: << >>  << T >>  << A >>

"Gabor";

> Am I missing something or did you paste the same code
> here twice?  Is this the code that caused XST to infer
> flip-flops?

Yup, sorry. The version infering the fliflops instead of srl16 clearly was:

  always @(posedge clk)
  begin
    if (cke) begin
      shiftdata[15:1] = shiftdata[14:0];
      shiftdata[0] = di;
    end
    if (cke2) begin  
      tmp = shiftdata[a];
    end
  end

Gruss

Jan Bruns


Article: 136504
Subject: Re: Aligned PLL clocks in RTL simulation
From: Jim Lewis <jim@synthworks.com>
Date: Wed, 19 Nov 2008 07:58:26 -0800
Links: << >>  << T >>  << A >>
Kim
>> We've easily enough got around this for the present
>> design, but I'd love to know what all you seasoned
>> PLL/DCM users out there do about it.  Do you introduce small non-zero 
>> time delays in all the
>> signals crossing the clock domains, so that it all
>> works in simulation?  Do you treat the various
> 
> At least one trick I use with modelsim is to force
> clock signal to the DCM outputs from the simulator.
> When forced signals are created they work on the same
> delta cycle. The same trick can be used also with asics
> that contain clock buffers for clock tree roots etc.
> 
> --Kim

This is good to know as VHDL-2008 gives you this capability
directly in code.

Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis    SynthWorks VHDL Training    http://www.synthworks.com

A bird in the hand may be worth two in the bush,
but it sure makes it hard to type.

Article: 136505
Subject: Re: opinion about various code generators
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 19 Nov 2008 08:07:20 -0800
Links: << >>  << T >>  << A >>
abe wrote:
> does anybody have a clear opinion about code generators ( c-> vhdl ,
> matlab-> vhdl, etc..) that are around? Are they really irreplaceable
> in complex applications (i.e DSP) as the vendors say?

My only clear opinion is that
many code generators create very ugly text.

I have used python and maple to work out the math
before I write my own code, and it seems plausible
to me that something like the matlab -> hdl products
*might* be practical.
I just haven't seen or heard any direct evidence.

       -- Mike Treseler

Article: 136506
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 19 Nov 2008 08:19:55 -0800
Links: << >>  << T >>  << A >>
Jan Bruns wrote:

> I didn't notice that xst now has better blocking assignment support
> (or maybe I got a false impression about older xst versions when
> learning verilog).

There has never been a synthesis problem
with blocking assignments.
However, it is possible for me to
make a simulation race this way
if I am not very careful.

      -- Mike Treseler

Article: 136507
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Nov 2008 08:28:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 10:07=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Gabor";
>
> > Am I missing something or did you paste the same code
> > here twice? =A0Is this the code that caused XST to infer
> > flip-flops?
>
> Yup, sorry. The version infering the fliflops instead of srl16 clearly wa=
s:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 end
>
> Gruss
>
> Jan Bruns

I see.  With the blocking assignments, this actually differs from
the original in the case where cke and cke2 are both asserted
on the same clock cycle.  In this case tmp will get shitdata[a]
after the shift has already occurred.  This does not fit the
standard template for SRL16, although you could probably
build it with an SRL16 and some extra logic on the address
inputs and realizing that it won't work for the zero-delay
case of a =3D 0 while both cke's are active.

Article: 136508
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 19 Nov 2008 17:40:08 +0100
Links: << >>  << T >>  << A >>

"Mike Treseler":
> Jan Bruns wrote:
 
>> I didn't notice that xst now has better blocking assignment support
>> (or maybe I got a false impression about older xst versions when
>> learning verilog).
 
> There has never been a synthesis problem
> with blocking assignments.
> However, it is possible for me to
> make a simulation race this way
> if I am not very careful.

Hm, maybe it just was a decision to "never" use blocking assignments 
for synthesis.

But I remember earlier xst complaining about many blocking assignment 
related things that should have been implmementable (errors or even crahes).

Gruss

Jan Bruns



Article: 136509
Subject: Re: USB JTAG
From: "Finn S. Nielsen" <removethis_finnstadel@vip.cybercity.dk>
Date: Wed, 19 Nov 2008 17:58:32 +0100
Links: << >>  << T >>  << A >>
John Evans skrev:
> Hello All,
> 
> Does anyone know if there is a cheaper alternative to the Xilinx USB 
> JTAG programmer. ? The price of $300 from avnet is rather expensive in 
> my opinion (and for my budget..).
> 
> I've been using xilinx cable IV, but it's not really working as reliable 
> or fast as one could wish for.
> 
> Another problem is that my laptop doesn't have a parallel port which is 
> very annoying.
> 
> Thanks,
> 
> John

Have a look at this place: www.morphologic.dk/shop

It's xilinx compatible...

Finn

Article: 136510
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Nov 2008 08:59:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 11:40=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Mike Treseler":
>
> > Jan Bruns wrote:
> >> I didn't notice that xst now has better blocking assignment support
> >> (or maybe I got a false impression about older xst versions when
> >> learning verilog).
> > There has never been a synthesis problem
> > with blocking assignments.
> > However, it is possible for me to
> > make a simulation race this way
> > if I am not very careful.
>
> Hm, maybe it just was a decision to "never" use blocking assignments
> for synthesis.
>
> But I remember earlier xst complaining about many blocking assignment
> related things that should have been implmementable (errors or even crahe=
s).
>
> Gruss
>
> Jan Bruns

Synthesizers use "templates" to fit things like flip-flops and SRL's.
When
a combination of blocking and non-blocking assignments does not fit a
template, the synthesizer throws up its hands and gives up.

That being said...

Your original code with only non-blocking assignments in the
clocked block is easier to fit because there is no combinatorial
logic implied after the clock.  Also the order of assignment only
matters in this case if you re-assign the same register, making
it easier to read, too.  This assignment order is not so apparent
in the version that inferred the flip-flops.  In that case you needed
to see that both if statements can occur under some conditions
causing the output assignment to come after the shift.

You can also get synthesis errors where it isn't obvious why,
like blocking assign in the asynchronous reset block but
non-blocking assigns in the clocked portion or vice-versa.

Article: 136511
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 19 Nov 2008 18:51:58 +0100
Links: << >>  << T >>  << A >>

"Gabor":
> Your original code with only non-blocking assignments in the
> clocked block is easier to fit because there is no combinatorial
> logic implied after the clock.

I think the non-blocking version would ideally sample data exactly 
when it per definition changes, effectively making no choice about
the data sampled beeing the older or the newer version.

Of course, it almost never makes sense to sample digital data when 
it is changing (except perhaps if you're interested in some kind of
random generator).

However, in contrast to the average usage of non-blocking assignments
(just sample a wire on a given event, without any additional constraints,
exactly the same thing real hardware can do), the non-blocking 
"shiftreg16F" code doesn't have implied semantics about the state
of the wire being sampled.


For exaample, in constructs like

  always @(someevent) begin
    somereg <= ~somereg;
  end

it is clear that it is equivalent to 

  wire somewire = ~somereg;
  always @(someevent) begin
    somereg <= somewire;
  end

giving a clear logical relationsship (following the from the practical
requirement) about what is to be assigned.

The original shiftreg16f code intnentionally merely did something like

  always @(someevent) begin
    somereg1 <= somewire;
    somereg2 <= somereg1;
  end

where minimal changes in clock-phase would produce opposite results.
Since xst tool does recognize the difference from

  always @(someevent) begin
    somereg1 = somewire;
    somereg2 = somereg1; // == somewire
  end

to the opposite

  always @(someevent) begin
    somereg2 = somereg1; // old value of somereg1
    somereg1 = somewire;
  end

I wouldn't expect it to produce "@clk(SRL+FF) within a slice" for
any of the two blocking versions, if none of the blocking versions
could be implmented that way.

Gruss

Jan Bruns


Article: 136512
Subject: Re: opinion about various code generators
From: Andy <jonesandy@comcast.net>
Date: Wed, 19 Nov 2008 10:03:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 10:07=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> abe wrote:
> > does anybody have a clear opinion about code generators ( c-> vhdl ,
> > matlab-> vhdl, etc..) that are around? Are they really irreplaceable
> > in complex applications (i.e DSP) as the vendors say?
>
> My only clear opinion is that
> many code generators create very ugly text.
>
> I have used python and maple to work out the math
> before I write my own code, and it seems plausible
> to me that something like the matlab -> hdl products
> *might* be practical.
> I just haven't seen or heard any direct evidence.
>
> =A0 =A0 =A0 =A0-- Mike Treseler

While I would hardly rate ANY product as "irreplaceable as its
vendors' claims," I have used CatapultC and found it helpful for
certain things, mostly in the form of "what-if" type trades. The tool
allows you to play around with a variety of input and output interface
types, and lets you see where expensive resources may be shared. The
best part is that it creates all the sequence control logic for
sharing resources for you, so evaluating different trades is less
painful. It also has a powerful tool for using original algorithmic
testing code in C to cosimulate with the HDL implementation in a
testbench.

It is in no way a tool for writing RTL in C, but at its untimed level
of abstraction, it does a good job in giving you the freedom to
relatively easily explore different effects on latency/throughput for
various implementations.

Andy

Article: 136513
Subject: Re: Linux on Microblaze
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 19 Nov 2008 12:06:15 -0800
Links: << >>  << T >>  << A >>
"Jan Bruns" <testzugang_janbruns@arcor.de> writes:
> What's the difference between uClinux and win32?

uClinux is an operating system derived from Linux.

Win32 is not an operating system or product.  It is a set of APIs
provided by multiple operating systems from Microsoft, and in some
cases by alternative products such as Wine and Wind/U.


Article: 136514
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 19 Nov 2008 12:47:54 -0800 (PST)
Links: << >>  << T >>  << A >>
Jan Bruns wrote:
> Hallo.
>
> When using a Spartan3 SliceM in 2x SRL16-Mode,
> the Slice-FlipFlops and the SRLs must share the same clock
> (and from the FPGA-Editor, it looks like if that clock's
> polarity must be the same for both, SRLs and FFs).
>
> Now, if I want to use the FFs (I don't think they can be
> used for anything else then buffering the SRL's Output),
> I'm not fully sure the FF clk will be early enough
> to not sample the SRL during undefined output.
>
> I think it's very likely that the FF clk is early enough,
> but I don't see a way to ask the xilinx tools about that
> (apart from the module attached compiles without errors
> in ISE10.1 web).
>
> Has anyone tried a simulation about this?
<snip>

Most precisely, the SRLs are designed to work with the local registers
without issue, adding one pipeline of delay.  The LUT memories act
just like LUTs when the data has settled its shift; any changes to the
shift register tap value results in an immediate (Tlut delay) change
to the output without regard for the clock.  When the clock edge
occurs, this settled value is latched in the FF (if you chose to use
it) before the shift data changes.  It doesn't "buffer" the shift
register data, it delays it by a clock.

You're correct that if you're using both LUTs as shift registers, the
bx and by inputs are feeding the shift registers and cannot be used by
the flops for any other purpose.  You can, however, have the output
from the shift register LUT separate from the accompanying register
allowing a separately clock-enabled version of the output strem to
exist with the always-enabled (from the mux-se4lect perspective)
version.

- John_H


Article: 136515
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 19 Nov 2008 22:37:29 +0100
Links: << >>  << T >>  << A >>

"John_H":
> Most precisely, the SRLs are designed to work with the local registers
> without issue, adding one pipeline of delay.  The LUT memories act
> just like LUTs when the data has settled its shift; any changes to the
> shift register tap value results in an immediate (Tlut delay) change
> to the output without regard for the clock.  When the clock edge
> occurs, this settled value is latched in the FF (if you chose to use
> it) before the shift data changes.  It doesn't "buffer" the shift
> register data, it delays it by a clock.
> 
> You're correct that if you're using both LUTs as shift registers, the
> bx and by inputs are feeding the shift registers and cannot be used by
> the flops for any other purpose.  You can, however, have the output
> from the shift register LUT separate from the accompanying register
> allowing a separately clock-enabled version of the output strem to
> exist with the always-enabled (from the mux-se4lect perspective)
> version.

Thanks for making that clear.

I am using that module to implement a byte-stream buffer. Using
an up/down-counter, I can store 0..16 bytes in just 2 Spartan3 CLBs,
allowing 2-sided, fully sequential access (and avoiding the need for
doubled SliceM consumption for DualPort distributed ram).
It was a bit long-winded to make xst use the SliceL carry chain
for the counter, so with my posting here, I intended to minimize
things to think about, just in case some kind of debug should become 
necessary.

Gruss

Jan Bruns




Article: 136516
Subject: Re: vga interfacing for image display
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 19 Nov 2008 15:31:09 -0700
Links: << >>  << T >>  << A >>
Mark McDougall wrote:

> Glen Herrmannsfeldt wrote:

>>Not the only option, but it is the best one.

> I've also heard of using PWM output on the RGB
> lines to produce more colours...

That is pretty much what my second suggestion was, though
with only three widths.  (0, 0.5, 1.0)

If you have a fast enough clock, you can generate more
different widths.

-- glen


Article: 136517
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Wed, 19 Nov 2008 23:32:51 +0100
Links: << >>  << T >>  << A >>

"Jan Bruns":
> I am using that module to implement a byte-stream buffer. Using
> an up/down-counter, I can store 0..16 bytes in just 2 Spartan3 CLBs,
> allowing 2-sided, fully sequential access (and avoiding the need for
> doubled SliceM consumption for DualPort distributed ram).
> It was a bit long-winded to make xst use the SliceL carry chain
> for the counter, so with my posting here, I intended to minimize
> things to think about, just in case some kind of debug should become 
> necessary.

Here's the design file. Maybe someone is interested in and(or may find bugs
(I haven't yet tested it at all, so I'm almost sure there's something
that doesn't already work als expected):

http://www.abnuto.de/jan/code/srlbuff16x8.v

Usage should be as follows:

  input clk;
  input ce;  // may be low for power saving
  input rst; // reset
// Receiver-side:
  output [7:0] do; // updated @(posedge clk), when down is true
  input down;
  output empty;    // if empty, don't let down-signal high
//Sender-Side:
  input [7:0] di;  // sampled @(posedge clk), if up is true
  input up;
  output full;     // if full, don't let up-signal high


Hoping this module isn't too extremely buggy.

Gruss

Jan Bruns


Article: 136518
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Nov 2008 15:25:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 12:51=A0pm, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Gabor":
>
> > Your original code with only non-blocking assignments in the
> > clocked block is easier to fit because there is no combinatorial
> > logic implied after the clock.
>
> I think the non-blocking version would ideally sample data exactly
> when it per definition changes, effectively making no choice about
> the data sampled beeing the older or the newer version.
>

Non-blocking assignment is designed specifically to PREVENT
this behavior.  i.e.  if all of your clocked processes use
non-blocking assigns, then none of your values will be sampled
after they change.  The clock edge forces all of the evaluations
to occur, and then a delta later (0 real time, but sequentially
for simulation) all of the assignments are performed.  So by
all means use non-blocking assignments in clocked blocks to
model actual flip-flop behavior when you don't want to REQUIRE
hold time in the simulation model.

> Of course, it almost never makes sense to sample digital data when
> it is changing (except perhaps if you're interested in some kind of
> random generator).
>
> However, in contrast to the average usage of non-blocking assignments
> (just sample a wire on a given event, without any additional constraints,
> exactly the same thing real hardware can do), the non-blocking
> "shiftreg16F" code doesn't have implied semantics about the state
> of the wire being sampled.
>
> For exaample, in constructs like
>
> =A0 always @(someevent) begin
> =A0 =A0 somereg <=3D ~somereg;
> =A0 end
>
> it is clear that it is equivalent to
>
> =A0 wire somewire =3D ~somereg;
> =A0 always @(someevent) begin
> =A0 =A0 somereg <=3D somewire;
> =A0 end
>
> giving a clear logical relationsship (following the from the practical
> requirement) about what is to be assigned.
>
> The original shiftreg16f code intnentionally merely did something like
>
> =A0 always @(someevent) begin
> =A0 =A0 somereg1 <=3D somewire;
> =A0 =A0 somereg2 <=3D somereg1;
> =A0 end
>
> where minimal changes in clock-phase would produce opposite results.
> Since xst tool does recognize the difference from
>
> =A0 always @(someevent) begin
> =A0 =A0 somereg1 =3D somewire;
> =A0 =A0 somereg2 =3D somereg1; // =3D=3D somewire
> =A0 end
>
> to the opposite
>
> =A0 always @(someevent) begin
> =A0 =A0 somereg2 =3D somereg1; // old value of somereg1
> =A0 =A0 somereg1 =3D somewire;
> =A0 end
>
> I wouldn't expect it to produce "@clk(SRL+FF) within a slice" for
> any of the two blocking versions, if none of the blocking versions
> could be implmented that way.
>
> Gruss
>
> Jan Bruns

Except that your first blocking version was essentially the same
as the non-blocking because there were no sequential assignments
to data which changed during one pass through the block.  You
can confirm this with a simulator.

Article: 136519
Subject: Re: how to implement an application with external memory in ISE?
From: KJ <lkjrsy@gmail.com>
Date: Wed, 19 Nov 2008 18:27:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 19, 5:29=A0am, Enes Erdin <eneser...@gmail.com> wrote:
> On 18 Kas=FDm, 18:37, KJ <lkj...@gmail.com> wrote:
>
> > Hi everyone.
>
> > For shortage of memory in FPGA, I need an exteranl memory.
> > In this case, is it possible to implement my application in ISE?
>
> > I means how to initiate the external memory in ISE tool.
> > If possible, I want to do simulation in PC without configuring it to
> > real board.
>
> You can download simulation models for the ram that you will use.
> Afterwards you should write a controller for it and you can use the
> model in your testbench.

Thanks for reply. I'm wondering where to download the simulation
models for the ram?

Article: 136520
Subject: ip core connection
From: deep <infoparajuli@gmail.com>
Date: Wed, 19 Nov 2008 23:57:34 -0800 (PST)
Links: << >>  << T >>  << A >>
hello everyone,
                     i am  trying to connect the ip core provided by
the xillinx for the vga port interface  with other multiple sources to
be interconnected to create entire new module in "spartan 3a 1800a dsp
fpga development board".if anybody is working or interested in the
above field can share the view on how to connect these ip cores.

Article: 136521
Subject: Altera DE3 - USB Bulk Transfer
From: Guy_FPGA <guybye@hotmail.com>
Date: Thu, 20 Nov 2008 00:33:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello all,
I have a DE3 board. I need to transfer data over the USB lines. As a
start I took the DE3_USB example and expanded it. In this example they
transmit 4 Bytes on the lines from the PC to the NIOS and back from
the NIOS to the PC.

I need to transfer 536B.
At first I used the Windows DDK bulk-transfer. The DDK supply an
example a consul application that opens a read pipe and a write pipe
and delivers the data through the pipes. I took the consul application
and extended it to transmit 536B and receive 536B as well.

OK- I can transmit 536B from the PC to the NIOS. But delivering data
back from the NIOS is always stuck at 128B. Lets get to some code:

If the NIOS execute:
BULK_Write(hBulk, szBulkDataOut, 536);
and the PC runs: ReadFile(hRead, pinBuf, 536, &nBytesRead, NULL);
then the PC is stuck... I mean it is still pending for data - the sw
is waiting - doesnt continue.
However:
NIOS: BULK_Write(hBulk, szBulkDataOut, 536);
PC : ReadFile(hRead, pinBuf, 128, &nBytesRead, NULL);
ReadFile(hRead, pinBuf, 128, &nBytesRead, NULL);
.....
.....
.....
then the PC gets only the first 128B and pending on the second
request.

even if I write:
NIOS: BULK_Write(hBulk, szBulkDataOut, 128);
BULK_Write(hBulk, szBulkDataOut, 128);
....
....
PC : ReadFile(hRead, pinBuf, 128, &nBytesRead, NULL);
ReadFile(hRead, pinBuf, 128, &nBytesRead, NULL);
.....
.....
.....

then the PC is pending on the second read.


SO....
1. How do I transfer data from NIOS to PC using the bulk transfer?
2. Do you know how to create a windows GUI project that communicate
with the USB?... I couldn't compile the rwbulk from DDK in windows I
needed the special make file of DDK and the special BUILD that comes
with the DDK as well.

Hope someone could help me out there....

Thanks a lot ...
Guy

Article: 136522
Subject: Re: how to implement an application with external memory in ISE?
From: Enes Erdin <eneserdin@gmail.com>
Date: Thu, 20 Nov 2008 00:36:43 -0800 (PST)
Links: << >>  << T >>  << A >>
> Thanks for reply. I'm wondering where to download the simulation
> models for the ram?

Actually the best thing you can do is -since you think of using an
external memory- find the suitable ram for you -IMHO speed, bus width,
controller design so on.. are extra jobs to search or do-. Most
probably the vendor will provide you a model or you can want one from
them.

For a simpler solution to try your code you can visit Cypress's web
site there you will find many simulation models and you can download
and use one of them.

Good luck.

Article: 136523
Subject: How could i play my SVF file correctly ?
From: bamboutcha9999@hotmail.com
Date: Thu, 20 Nov 2008 01:27:33 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi folks,
When trying to execute my SVF file , Impact software provided by
Xilinx issues errors like :

ScanDR 32 TDI(00000000) TDO(F286E093) Mask(0FFFFFFF) Smask(FFFFFFFF)
ERROR:iMPACT - Failed ScanDR: TDO does not match Expected TDO
ERROR:iMPACT - TDO ReadBack
: 00000001
ERROR:iMPACT - TDO Expected
: f286e093
EXCEPTION:iMPACT:SVFReader.c:335:1.20.14.1 - Scan Data Mismatch.
INFO:iMPACT:2146 - Play svf failed.
PROGRESS_END - End Operation.
Elapsed time =      1 sec.11111

Moreover i want to want to know why within SVF file the ID check
instruction is executed twice ? one with MASK and  other one  without
MASK ? This conecrns also HIR,TIR,HDR,TDR  instructions :

//Loading device with 'idcode' instruction.
SIR 10 TDI (03c9) SMASK (03ff) ;
SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f286e093) MASK
(0fffffff) ;
TIR 0 ;
HIR 0 ;
TDR 0 ;
HDR 0 ;
TIR 0 ;
HIR 0 ;
TDR 0 ;
HDR 0 ;
TIR 0 ;
HIR 0 ;
HDR 0 ;
TDR 0 ;
//Loading device with 'idcode' instruction.
SIR 10 TDI (03c9) ;
SDR 32 TDI (00000000) TDO (f286e093) ;

Article: 136524
Subject: Re: Spartan3 SRL16 + SliceFF, LUT stability
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Thu, 20 Nov 2008 11:32:00 +0100
Links: << >>  << T >>  << A >>

"Gabor":
>On Nov 19, 12:51 pm, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
>> "Gabor":
>>
>> > Your original code with only non-blocking assignments in the
>> > clocked block is easier to fit because there is no combinatorial
>> > logic implied after the clock.
>>
>> I think the non-blocking version would ideally sample data exactly
>> when it per definition changes, effectively making no choice about
>> the data sampled beeing the older or the newer version.
>>

>Non-blocking assignment is designed specifically to PREVENT
>this behavior.  i.e.  if all of your clocked processes use
>non-blocking assigns, then none of your values will be sampled
>after they change.  The clock edge forces all of the evaluations
>to occur, and then a delta later (0 real time, but sequentially
>for simulation) all of the assignments are performed.  So by
>all means use non-blocking assignments in clocked blocks to
>model actual flip-flop behavior when you don't want to REQUIRE
>hold time in the simulation model.

> Of course, it almost never makes sense to sample digital data when
> it is changing (except perhaps if you're interested in some kind of
> random generator).
>
> However, in contrast to the average usage of non-blocking assignments
> (just sample a wire on a given event, without any additional constraints,
> exactly the same thing real hardware can do), the non-blocking
> "shiftreg16F" code doesn't have implied semantics about the state
> of the wire being sampled.
>
> For exaample, in constructs like
>
> always @(someevent) begin
> somereg <= ~somereg;
> end
>
> it is clear that it is equivalent to
>
> wire somewire = ~somereg;
> always @(someevent) begin
> somereg <= somewire;
> end
>
> giving a clear logical relationsship (following the from the practical
> requirement) about what is to be assigned.
>
> The original shiftreg16f code intnentionally merely did something like
>
> always @(someevent) begin
> somereg1 <= somewire;
> somereg2 <= somereg1;
> end
>
> where minimal changes in clock-phase would produce opposite results.
> Since xst tool does recognize the difference from
>
> always @(someevent) begin
> somereg1 = somewire;
> somereg2 = somereg1; // == somewire
> end
>
> to the opposite
>
> always @(someevent) begin
> somereg2 = somereg1; // old value of somereg1
> somereg1 = somewire;
> end
>
> I wouldn't expect it to produce "@clk(SRL+FF) within a slice" for
> any of the two blocking versions, if none of the blocking versions
> could be implmented that way.
>
> Gruss
>
> Jan Bruns

Except that your first blocking version was essentially the same
as the non-blocking because there were no sequential assignments
to data which changed during one pass through the block.  You
can confirm this with a simulator.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search