Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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" > endmoduleArticle: 136501
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 BrunsArticle: 136502
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, AlesArticle: 136503
"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: 136504Kim >> 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
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
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: 136507On 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
"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 BrunsArticle: 136509
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... FinnArticle: 136510
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
"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: 136512On 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. AndyArticle: 136513
"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
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_HArticle: 136515
"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 BrunsArticle: 136516
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. -- glenArticle: 136517
"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 BrunsArticle: 136518
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
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
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: 136521Hello 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 ... GuyArticle: 136522
> 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
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
"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:
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