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 Sat, 05 Apr 2008 01:28:54 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >rickman wrote: >(snip) > >> Actually, it is not that you *can* produce all logic from NAND gates, >> in effect that is how it *is* done. The basic logic element consists >> of transistors configured to be a NAND gate, an inverter (a degenerate >> form of a NAND gate), a NOR gate (a NAND gate with inverted logic) and >> transmission gates. So inside of a chip designed at the gate level, >> there really is no distinction between NAND and NOR gates and there >> are no OR and AND gates. > >I believe that is pretty much true for TTL, and I believe >also for ECL, PMOS and NMOS, but not for CMOS. ECL is OR/NOR, since it is basically a differential pair (with multiple transistors in parallel with the left transistor for multiple input gates) and the output can be taken (using an emitter follower) from either collector resistor of the differential pair to get OR or NOR functionality. If the output is taken from both sides, there are simultaneous OR and NOR outputs. In ECL the EXOR gate can be implemented by replacing the differential pair collector resistors with two additional differential pairs as in a Gilbert cell mixer (MC1496 style). PaulArticle: 130926
Joseph wrote: > Hi all, > > I am looking for the datasheet of the PLS161 which was a PLA. My > interest in it is purely academic. I am teaching a high level digital > electronics course and would like my students to see a datasheet of a > PLA before progressing to CPLD and FPGA's > > I would be very grateful if someone could give me the datasheet of > this device or a similar PLA. > > Many thanks Try the PLC42VA12 ? Quite clear drawings, and a descendent of the PLS161 http://www.nxp.com/acrobat_download/datasheets/PC42VA12.pdf and this simpler sibling ? http://www.nxp.com/acrobat_download/datasheets/PLC18V8Z.pdf Those two, should give a reasonable stepping stone sequence. The CoolRunner still has aspects of PLA (able to share product terms) but the data sheets are not as well drawn. -jgArticle: 130927
Jim Granville wrote: > Joseph wrote: > >> Hi all, >> >> I am looking for the datasheet of the PLS161 which was a PLA. My >> interest in it is purely academic. I am teaching a high level digital >> electronics course and would like my students to see a datasheet of a >> PLA before progressing to CPLD and FPGA's >> >> I would be very grateful if someone could give me the datasheet of >> this device or a similar PLA. >> >> Many thanks > > > Try the PLC42VA12 ? > Quite clear drawings, and a descendent of the PLS161 > > http://www.nxp.com/acrobat_download/datasheets/PC42VA12.pdf > > and this simpler sibling ? > http://www.nxp.com/acrobat_download/datasheets/PLC18V8Z.pdf > > Those two, should give a reasonable stepping stone sequence. > > The CoolRunner still has aspects of PLA (able to share product terms) > but the data sheets are not as well drawn. I'll add a bit more: For current production devices, look at Atmel who have SPLD and CPLD. http://www.atmel.com/dyn/products/datasheets.asp?family_id=653 http://www.atmel.com/dyn/products/other_docs.asp?family_id=653 A good CPLD Macrocell drawing is here: http://www.atmel.com/dyn/resources/prod_documents/doc3659.pdf Atmel tool flows are small and nimble, and can fit on a USB Flash Drive. So, if you wanted, students could actually compile something, or you could set some homework to have them change some aspect of an example design. The FIT report files are very readable, so they hand those in, and you mark that. -jgArticle: 130928
On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Lukats@googlemail.com> wrote: >On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote: >> On 1 Apr., 14:31, "Nial Stewart" >> >> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: >> > I've read all the posts here but have lost track of how you're >> > getting on. >> >> > Can you post an update and describe what the problem turned out >> > to be? >> >> > Nial. >> >> Quote from Actel website: "In March 2008, it was discovered that a >> potential advanced optimization could cause a logic gating of a global >> signal. >> This is fixed in Libero 8.3 released march 31 2008 >updating to 8.3 did not fix the problems, but I am getting closer >status: >in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi >slave from ext mcu) > >loadable LFSR in A1 domain >2:1 MUX for the selecting the load value >1 input of mux = const, loaded at powerup >2 input of mux connected to 24 bit shift register in A2 domain > >LFSR is loaded with constant at powerup, and loaded >with current value in spi shift register ONCE, after >that load the load enable signal is FULLY DISABLED >but when the there is data shifted in into the spi shift >register connected to the input mux of the LFSR load input >then some sequences of data make the LFSR content corrupt > >these sequences are REPEATABLE, that is not random! As I understand it, the SPI register and the LFSR register are on different clock domains; with purely combinational logic (the mux, and the Load Enable) between them. In Xilinx, as I understand it, if a 4-Lut transitions between one Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed not to glitch via a Load_Enable=True state. I don't know Actel at all - is the same guarantee true there? If not, I believe you need an intermediate register (just a simple pipeline register) clocked in the LFSR clock domain, to hold a copy of the SPI shift register. (This copy is subject to metastability, but with a tiny window of opportunity). Whereas now, you are exposed to the possibility of glitches derived from the SPI clock, and latched on the LFSR clock. > That is the LFSR gets corrupted at certaing >values being visible on the load input via mux ... or certain TRANSITIONS being visible on the load input? IF the mux and the load enable logic are rolled into the same combinational cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values during a settling time window after the ... wrong clock. >I already have forced the LFSR enable and mux select >to global clocks I'm not sure that helps (it may reduce errors by an order of magnitude or more, but it leaves you open to the possibility above) >of course the SPI clock and LFSR clocks are global >clocks as well ... good... just a guess but on the information given, it looks plausible to me. - BrianArticle: 130929
On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@googlemail.com> > wrote: > > > > >On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote: > >> On 1 Apr., 14:31, "Nial Stewart" > > >> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > >> > I've read all the posts here but have lost track of how you're > >> > getting on. > > >> > Can you post an update and describe what the problem turned out > >> > to be? > > >> > Nial. > > >> Quote from Actel website: "In March 2008, it was discovered that a > >> potential advanced optimization could cause a logic gating of a global > >> signal. > >> This is fixed in Libero 8.3 released march 31 2008 > >updating to 8.3 did not fix the problems, but I am getting closer > >status: > >in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi > >slave from ext mcu) > > >loadable LFSR in A1 domain > >2:1 MUX for the selecting the load value > >1 input of mux = const, loaded at powerup > >2 input of mux connected to 24 bit shift register in A2 domain > > >LFSR is loaded with constant at powerup, and loaded > >with current value in spi shift register ONCE, after > >that load the load enable signal is FULLY DISABLED > >but when the there is data shifted in into the spi shift > >register connected to the input mux of the LFSR load input > >then some sequences of data make the LFSR content corrupt > > >these sequences are REPEATABLE, that is not random! > > As I understand it, the SPI register and the LFSR register are on different > clock domains; with purely combinational logic (the mux, and the Load Enable) > between them. > > In Xilinx, as I understand it, if a 4-Lut transitions between one > Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed > not to glitch via a Load_Enable=True state. > > I don't know Actel at all - is the same guarantee true there? > > If not, I believe you need an intermediate register (just a simple pipeline > register) clocked in the LFSR clock domain, to hold a copy of the SPI shift > register. (This copy is subject to metastability, but with a tiny window of > opportunity). Whereas now, you are exposed to the possibility of glitches > derived from the SPI clock, and latched on the LFSR clock. > > > That is the LFSR gets corrupted at certaing > >values being visible on the load input via mux > > ... or certain TRANSITIONS being visible on the load input? > > IF the mux and the load enable logic are rolled into the same combinational > cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values > during a settling time window after the ... wrong clock. > > >I already have forced the LFSR enable and mux select > >to global clocks > > I'm not sure that helps (it may reduce errors by an order of magnitude or more, > but it leaves you open to the possibility above) > > >of course the SPI clock and LFSR clocks are global > >clocks as well > > ... good... > > just a guess but on the information given, it looks plausible to me. > > - Brian Hi Brian, the story goes even more fascinating (or frustrating)... first about Actel - their Logic Cell is NOT LUT based, so the LUT input transition glitches can not happen (no LUT!) but actel cell has NO DEDICATED flip-flop, and flip flops are configured out of logic, and have severe restrictions on configuration and routing, FF with enable and clear are made out 2 cells if CLR signal is not driven by global clock sometimes 4 cells are used to make 1 single flip flop. the use of global clocks in actel, sometimes its not "order of magnitude" difference but simple OK vs FAIL 100% issue case: 64 bit shift register (no enable just shift), clocked with CLEAN clock at 4mhz work 100% when FPGA is almost empty (no matter what signal drivers shift reg clock) fails 100% when FPGA is >90% and shift clock is ruouted with local connects PROVEN. this is also explanaibale, and actel has special appnote for this (clock skew handling) == now to my clocking issue after taking a break I tried to eliminate things from the problem, so I stopped shifting data into the SPI shift register. this however made no difference, and when i looked again it was also explanaible as my test counter value was decoded in external AR MCU but the bytes holding the counter value did never get back into the FPGA! so to summarize again: 1) ARM9 SW has counter, that is used to generate 8 byte encrypted token 2) those 8 bytes are going into FPGA over A1 parallel interface they are written into dual port BRAM 3) those 8 bytes are read by AVR over SPI interface 4) AVR decodes those bytes, it also decodes the counter from step 1, NO ERROR ever here 5) AVR writes 3 bytes to FPGA SPI shift register 6) AVR strobes to load LFSR, and set one time flag that prevents further LFSR loads 7) ARM9 sends packets in loop (encrypted counter) now, the counter value NEVER exist inside FPGA the data passed via FPGA is not decoded there the data passed via FPGA is not used by the logic responsible for the load/enable of the LFSR still at some certain counter value, the LFSR does get corrupted!! those values are repeatable, they are not random, that is each time the ARM9 counter is restarted then at exactly same counter values the LFSR is corrupted. those values are however different for different PCB+bitstream combinations 8) AVR puts FPGA into main mode 9) ARM9 sends any packets any number of hours LFSR corruption no longer happens! no single errror seen errors happen at [7] at const numbers of counter error NEVER happen at [9] while streaming random data for hours.. so there is no different transitions on the load input of the LFSR at all, still there is repeatable dependancy on the data stream that only passes through FPGA eeee... [8] what happens there? well after main mode the AVR no longer collects data from FPGA and no longer decrypts it. but that should no have any influence as the decrypt result wasnt passing into the FPGA anyway. there is one more difference, after [8] the LFSR is enabled for 8 clocks lonfer for each packet from A1 interface but the LFSR enable/load signals do not share any logic with any of the data lines !! Ok, when found out that the counter data is not passing into the load input at all, i did take a walk and coffee break, and did write a list of options that can be tested, list with 6 items, so will work them out one by one my bet is that I need add delay on the LFSR enable signal, there is no explanation why it should be used as it is already a FF in the same clock domain as the LFSR clock, but all other items on my list of possible problems are even less likely (or harder to test) AnttiArticle: 130930
ni wrote:
> I have recently started(1 week) using Synplify pro. For two years in
> my fpga designs I never used synplify pro. For most of the generic
> component I used to use core generator and then instantiate those
> component in my vhdl code.
Next time post to comp.lang.vhdl.
Start with the Synplify pro vhdl synthesis guide.
Most of the core generator blocks can be replaced by a few
lines of vhdl code, but there is a learning period.
Here's some brand A examples :
http://www.altera.com/support/examples/vhdl/vhdl.html
Here's some brand X examples :
http://www.xilinx.com/support/documentation/hdl_and_synthesis.htm
Here are my examples.
http://home.comcast.net/~mike_treseler/
Good luck.
-- Mike Treseler
Article: 130931On Mar 23, 4:01 pm, pmull...@yahoo.com wrote: > On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com... > > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote: > > > >> > but as the V5FX has been delaying so long, I have almost lost interest > > >> > to follow up how much longer it is delaying in reality... > > > >> > The Spartan-4 is much more interesting, > > > >> Well, we are desperately waiting for the V5 MGTs. > > >> Actually we need a solution for 10gbps soon as XAUI is going to be > > >> replaced > > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports. > > > >> Kolja Sulimma > > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed of > > > MGTs > > > V4 less than V2 > > > V5 less than V4 > > > > so you may need wait V6 :( > > > > Antti > > > V6? Don't hold your breath. > > > A reliable source tells me that the 10Gbps serdes will be fully functional > > in V12 Pro (they're skipping V13 for obvious reasons). > > > Bob > > I would check with Altera on Serdes as they have done it right and > have been up to 6 Gbps for years. As shown on the homepage of Xilinx, the new Virtex5 FXT is out now. Does anybody know whether there is development board featured with Virtex5 FXT available? Is that ML507, if so where is the info or data sheet for this board? SimonArticle: 130932
maverick wrote: > I need to know how can I prohibit a configuration file from being > downloaded on a similar FPGA device. How about adding an XC2C32 CPLD to the board and routing all of the bitstream data through it? Since it is flash based you could put a unique key in each one at board build time and use the key to encode/decode the bitstream. This does not give good protection since a digital scope on the DIN and CCLK pins would give the unencrypted bitstream but it might be enough for your needs. The XC2C32 is a little over a buck in 100 quantity at Digi-Key. HTH Bob SmithArticle: 130933
On 5 Apr., 20:30, Bob Smith <use...@linuxtoys.org> wrote: > maverick wrote: > > I need to know how can I prohibit a configuration file from being > > downloaded on a similar FPGA device. > > How about adding an XC2C32 CPLD to the board and routing all > of the bitstream data through it? Since it is flash based > you could put a unique key in each one at board build time > and use the key to encode/decode the bitstream. This does > not give good protection since a digital scope on the DIN > and CCLK pins would give the unencrypted bitstream but it > might be enough for your needs. The XC2C32 is a little over > a buck in 100 quantity at Digi-Key. > > HTH > Bob Smith the OP wants COTS board to be used 1) with no mods to the board 2) with no additions to the board so adding anything isnt an option AnttiArticle: 130934
referringto@googlemail.com wrote: > It was the next challenge after maxing out on CPLDs (see > http://www.opencores.org/projects.cgi/web/mcpu/overview). This looked nifty, so I've downloaded this and had a quick try : Could not fit into a 9536, or 9536XL - just too many product terms. (with default settings), so it bumped to the 72MC devices, just over 50% full. Auto-Fitted in XC2C64, but generated 34MC's. (SIZE optimised), but PT looks OK for a smaller device. However, I did see it generated a number of intermediate Macrocells.... Hmmm... so I switched to Speed, thinking that might avoid some intermediate MCs - and, strangely, Speed optimised now FITS XC2C32A,where SIZE failed :) Only just, but as your target was 32MC's this counts as a PASS! [ Need to find something for that extra MC and 3PTs to do :) - maybe a Debug/Trace LED ?, could select 1 of 3 probe points ? ] RESOURCES SUMMARY Design Name cpu8bit2 Device XC2C32-3-PC44 Macrocells Used 31/32 (97%) Pterms Used 109/112(98%) Registers Used 24/32 (75%) Pins Used 18/33 (55%) Function Block Inputs Used 70/80 (88%) You could add this newer device to your 32 MCell supported list. ( and I'd suggest appending the full FIT cpu8bit2.rpt file to the PDFs ) -jgArticle: 130935
On Apr 5, 11:12=A0am, Simon <wlpstx...@gmail.com> wrote: > On Mar 23, 4:01 pm, pmull...@yahoo.com wrote: > > > > > On Mar 3, 10:22 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > > > > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > > >news:ee42d07c-3062-489e-93b1-d9afa01fbbac@y77g2000hsy.googlegroups.com.= .. > > > > > On 3 Mrz., 17:15, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > >> On 3 Mrz., 11:20, Antti <Antti.Luk...@googlemail.com> wrote: > > > > >> > but as the V5FX has been delaying so long, I have almost lost int= erest > > > >> > to follow up how much longer it is delaying in reality... > > > > >> > The Spartan-4 is much more interesting, > > > > >> Well, we are desperately waiting for the V5 MGTs. > > > >> Actually we need a solution for 10gbps soon as XAUI is going to be > > > >> replaced > > > >> by SFP+ really soon. We can't place external 10G serdes on 12 ports= . > > > > >> Kolja Sulimma > > > > > well EVERY new xilinx family since V2ProX is DOWNGRADING the speed o= f > > > > MGTs > > > > V4 less than V2 > > > > V5 less than V4 > > > > > so you may need wait V6 :( > > > > > Antti > > > > V6? Don't hold your breath. > > > > A reliable source tells me that the 10Gbps serdes will be fully functi= onal > > > in V12 Pro (they're skipping V13 for obvious reasons). > > > > Bob > > > I would check with Altera on Serdes as they have done it right and > > have been up to 6 Gbps for years. > > As shown on the homepage of Xilinx, the new Virtex5 FXT is out now. > Does anybody know whether there is development board featured with > Virtex5 FXT available? Is that ML507, if so where is the info or data > sheet for this board? > > Simon To the best of my knowledge, the ML507 board is identical in layout and appearance with the ML505 board, since the 'LXT and 'FXT chips are pin-compatible. Let's see on Monday at work... Peter AlfkeArticle: 130936
> I am trying to prohibit generation of multiple copies of the > same system. For example, assume that I have developed a system which > comprises of a PC and a PCI based FPGA board which is mounted on the > PCI slot of the same PC. The PCI based FPGA board is commercially > availble from a vendor. The host application that runs on the PC > programs the FPGA on application startup. Every PCI slot on a PC has a unique bus/slot number that you could use to selectively download fpga code. Unfortunately, the mapping between these numbers and the physical slot is not always obvious. If you have two identical cards and no way to tell them apart, you are going to need some sort of user intervention to select which card to program. The mental telepathy option is usually disabled in the BIOS. Actually, if the cards are truly identical, then it shouldn't matter which one you program. Just program the first one you find and assume there aren't any others. Alan NishiokaArticle: 130937
The following code runs well in simulation mode but synthesis fails.
Please let me know how I can get this synthesized, thanks!
Fei
`timescale 1ns / 1ps
module blink_led(clk, d, led);
input clk;
input d;
output wire led;
parameter blink_freq = 2;
reg [blink_freq:0] count = 0;
reg [1:0] state = 0;
reg [1:0] next_state = 0;
assign led = !count[blink_freq];
always @(posedge clk)
begin
state <= next_state;
if(state == 2'b01)
begin
count <= count + 1;
if(count[blink_freq])
next_state <= 2'b10;
else
next_state <= 2'b01;
end
end
always @(state or d) begin
case(state)
2'b00:
if(d)
next_state <= 2'b01;
else
next_state <= 2'b00;
2'b01:
begin
count <= count + 1;
if(count[blink_freq])
next_state <= 2'b10;
else
next_state <= 2'b01;
end
2'b10:
begin
count <= 0;
next_state <= 2'b00;
end
default:
begin
next_state <= state;
end
endcase
end
endmodule
module stimuli;
reg clk=0;
reg d=0;
wire led;
blink_led bl(.clk (clk), .d(d), .led(led));
initial
forever #20 clk = ~clk;
initial begin
#80 d = 1;
#40 d = 0;
#140 d = 1;
forever #40 d = ~d;
end
endmodule
ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub0000_cy<0>>
Sources are:
Output signal of LD instance <count_ren_0>
Output signal of FDE instance <count_0>
ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub00002>
Sources are:
Output signal of LD instance <count_ren_1>
Output signal of FDE instance <count_1>
ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal
<Madd_count_addsub00004>
Sources are:
Output signal of LD instance <count_ren_2>
Output signal of FDE instance <count_2>
CPU : 6.41 / 6.66 s | Elapsed : 7.00 / 7.00 s
-->
Total memory usage is 154044 kilobytes
Number of errors : 3 ( 0 filtered)
Number of warnings : 2 ( 0 filtered)
Number of infos : 1 ( 0 filtered)
Process "Synthesize" failed
Article: 130938
On Apr 5, 9:17 pm, Fei Liu <fei....@gmail.com> wrote:
> The following code runs well in simulation mode but synthesis fails.
> Please let me know how I can get this synthesized, thanks!
>
> Fei
I've managed to code this to get synthesis done but I don't understand
why next_state can be assigned in both always blocks but count cannot?
The only difference is count update depends on count itself...
`timescale 1ns / 1ps
module blink_led(clk, d, led);
input clk;
input d;
output wire led;
parameter blink_freq = 2;
reg [blink_freq:0] count = 0;
reg [1:0] state = 0;
reg [1:0] next_state = 0;
assign led = !count[blink_freq];
always @(posedge clk)
begin
state <= next_state;
case(state)
2'b01:
begin
count <= count + 1;
if(count[blink_freq])
next_state <= 2'b10;
else
next_state <= 2'b01;
end
2'b10:
count <= 0;
endcase
end
always @(state or d or count) begin
case(state)
2'b00:
if(d)
next_state <= 2'b01;
else
next_state <= 2'b00;
2'b01:
begin
if(count[blink_freq])
next_state <= 2'b10;
else
next_state <= 2'b01;
end
2'b10:
begin
next_state <= 2'b00;
end
default:
begin
next_state <= state;
end
endcase
end
endmodule
module stimuli;
reg clk=0;
reg d=0;
wire led;
blink_led bl(.clk (clk), .d(d), .led(led));
initial
forever #20 clk = ~clk;
initial begin
#80 d = 1;
#40 d = 0;
#140 d = 1;
forever #40 d = ~d;
end
endmodule
Article: 130939Fei Liu wrote: > The following code runs well in simulation mode but synthesis fails. > Please let me know how I can get this synthesized, thanks! (snip) > blink_led bl(.clk (clk), .d(d), .led(led)); > > initial > forever #20 clk = ~clk; > > initial begin > #80 d = 1; > #40 d = 0; > #140 d = 1; > forever #40 d = ~d; > end It is usual not to be able to synthesize the above logic. Pretty much anything with a numeric delay won't synthesize. > ERROR:Xst:528 - Multi-source in Unit <blink_led> on signal > <Madd_count_addsub0000_cy<0>> > Sources are: > Output signal of LD instance <count_ren_0> > Output signal of FDE instance <count_0> This means there are two outputs connected together. You can't do that in real logic as the output drivers will fight each other, often with large currents flowing. Without going all the way through the logic, I believe it is count that has more than one source. -- glenArticle: 130940
On Sat, 5 Apr 2008 18:17:24 -0700 (PDT), Fei Liu <fei.liu@gmail.com> wrote: >The following code runs well in simulation mode but synthesis fails. >Please let me know how I can get this synthesized, thanks! I'm assuming you're not trying to synthesize your test-bench ie module stimuli. You can only synthesize blink_led and if you want to exercise it after synthesis, you can use the gate level version under your test-bench or implement in an fpga and drive the pins on the board. As to synthesizing the blink_led module, you need to make sure that any signal is driven from only one always block. Put all next_state and count assignments to the second (combinational) block. You can add another set of wires for something like count_d and assign it in the second block (ie count_d = count + 1; etc) and add count <= count_d; to your first (sequential) block unconditionally. Your code should look as follows: always @(posedge clk) begin state <= next_state; count <= count_d; end always @(*) begin case (state) ... next_state = foo; count_d = count + 1; ... end Muzaffer Kal ASIC/FPGA Design Services DSPIA INC. http://www.dspia.comArticle: 130941
On Apr 6, 12:01 am, Muzaffer Kal <k...@dspia.com> wrote:
> On Sat, 5 Apr 2008 18:17:24 -0700 (PDT), Fei Liu <fei....@gmail.com>
> wrote:
>
> >The following code runs well in simulation mode but synthesis fails.
> >Please let me know how I can get this synthesized, thanks!
>
> I'm assuming you're not trying to synthesize your test-bench ie module
> stimuli. You can only synthesize blink_led and if you want to exercise
> it after synthesis, you can use the gate level version under your
> test-bench or implement in an fpga and drive the pins on the board.
>
> As to synthesizing the blink_led module, you need to make sure that
> any signal is driven from only one always block. Put all next_state
> and count assignments to the second (combinational) block. You can add
> another set of wires for something like count_d and assign it in the
> second block (ie count_d = count + 1; etc) and add count <= count_d;
> to your first (sequential) block unconditionally.
> Your code should look as follows:
>
> always @(posedge clk)
> begin
> state <= next_state;
> count <= count_d;
> end
>
> always @(*)
> begin
> case (state)
> ...
> next_state = foo;
> count_d = count + 1;
> ...
> end
>
> Muzaffer Kal
> ASIC/FPGA Design Services
> DSPIA INC.http://www.dspia.com
Thanks, I think my second iteration does exactly what you described
here. I do have one last doubt about timing. In my synthesizable
version, when I run the test bench, the value of state always lags
behind next_state for 1 or half clock period. My understanding is that
since they are in separate always blocks, the simulation is free to do
this assignment with a delay. Is there a deeper reason why state value
always lag behind next_state for 1 clk?
clk period = 40
0 clk = 0, d = 0, led = 0, state = 00, next_state =
00
20 clk = 1, d = 0, led = 0, state = 00, next_state =
00
40 clk = 0, d = 0, led = 0, state = 00, next_state =
00
60 clk = 1, d = 0, led = 0, state = 00, next_state =
00
80 clk = 0, d = 1, led = 0, state = 00, next_state =
01 <---
100 clk = 1, d = 1, led = 1, state = 01, next_state =
01 <---
120 clk = 0, d = 0, led = 1, state = 01, next_state =
01
140 clk = 1, d = 0, led = 1, state = 01, next_state =
01
160 clk = 0, d = 0, led = 1, state = 01, next_state =
01
180 clk = 1, d = 0, led = 1, state = 01, next_state =
01
200 clk = 0, d = 0, led = 1, state = 01, next_state =
01
220 clk = 1, d = 0, led = 1, state = 01, next_state =
01
240 clk = 0, d = 0, led = 1, state = 01, next_state =
01 <---
260 clk = 1, d = 1, led = 1, state = 01, next_state =
10 <---
280 clk = 0, d = 1, led = 1, state = 01, next_state =
10
300 clk = 1, d = 0, led = 0, state = 10, next_state =
00
320 clk = 0, d = 0, led = 0, state = 10, next_state =
00
340 clk = 1, d = 0, led = 0, state = 00, next_state =
00
360 clk = 0, d = 0, led = 0, state = 00, next_state =
00
380 clk = 1, d = 0, led = 0, state = 00, next_state =
00
400 clk = 0, d = 1, led = 0, state = 00, next_state =
01
420 clk = 1, d = 1, led = 1, state = 01, next_state =
01
440 clk = 0, d = 0, led = 1, state = 01, next_state =
01
460 clk = 1, d = 0, led = 1, state = 01, next_state =
01
480 clk = 0, d = 0, led = 1, state = 01, next_state =
01
500 clk = 1, d = 0, led = 1, state = 01, next_state =
01
520 clk = 0, d = 0, led = 1, state = 01, next_state =
01
540 clk = 1, d = 0, led = 1, state = 01, next_state =
01
560 clk = 0, d = 0, led = 1, state = 01, next_state =
01
580 clk = 1, d = 0, led = 1, state = 01, next_state =
10 <----
600 clk = 0, d = 0, led = 1, state = 01, next_state =
10
620 clk = 1, d = 0, led = 0, state = 10, next_state =
00 <----
640 clk = 0, d = 0, led = 0, state = 10, next_state =
00
660 clk = 1, d = 0, led = 0, state = 00, next_state =
00
680 clk = 0, d = 0, led = 0, state = 00, next_state =
00
700 clk = 1, d = 0, led = 0, state = 00, next_state =
00
720 clk = 0, d = 0, led = 0, state = 00, next_state =
00
740 clk = 1, d = 0, led = 0, state = 00, next_state =
00
760 clk = 0, d = 0, led = 0, state = 00, next_state =
00
780 clk = 1, d = 0, led = 0, state = 00, next_state =
00
800 clk = 0, d = 0, led = 0, state = 00, next_state =
00
820 clk = 1, d = 0, led = 0, state = 00, next_state =
00
840 clk = 0, d = 0, led = 0, state = 00, next_state =
00
860 clk = 1, d = 0, led = 0, state = 00, next_state =
00
880 clk = 0, d = 0, led = 0, state = 00, next_state =
00
900 clk = 1, d = 0, led = 0, state = 00, next_state =
00
920 clk = 0, d = 0, led = 0, state = 00, next_state =
00
940 clk = 1, d = 0, led = 0, state = 00, next_state =
00
960 clk = 0, d = 0, led = 0, state = 00, next_state =
00
980 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1000 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1020 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1040 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1060 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1080 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1100 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1120 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1140 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1160 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1180 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1200 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1220 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1240 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1260 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1280 clk = 0, d = 0, led = 0, state = 00, next_state =
00
1300 clk = 1, d = 0, led = 0, state = 00, next_state =
00
1320 clk = 0, d = 0, led = 0, state = 00, next_state =
00
Also of course I wasn't trying to synthesize the test bench code...
Thanks,
Article: 130942On Sat, 5 Apr 2008 21:35:52 -0700 (PDT), Fei Liu <fei.liu@gmail.com> wrote: >Thanks, I think my second iteration does exactly what you described >here. I do have one last doubt about timing. In my synthesizable >version, when I run the test bench, the value of state always lags >behind next_state for 1 or half clock period. My understanding is that >since they are in separate always blocks, the simulation is free to do >this assignment with a delay. Is there a deeper reason why state value >always lag behind next_state for 1 clk? Actually there is. This is exactly how sequential logic is supposed to work. At every positive edge of the clock the registers store the value at their input and their output changes. This is accomplished by the first always block. Then the combinational always block takes the register outputs and calculates the next cycle's values which are not noticed by the registers till the next clock. With actual logic delays, the calculation of the next state can take almost all the period of a single cycle so correct data may not arrive at the input of the registers till almost the next clock cycle has arrived. If clock arrives after the next state is calculated it is said that the circuit "meets timing".Article: 130943
On 5 Apr., 19:37, Antti <Antti.Luk...@googlemail.com> wrote: > On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote: > > > > > On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@googlemail.com> > > wrote: > > > >On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote: > > >> On 1 Apr., 14:31, "Nial Stewart" > > > >> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > >> > I've read all the posts here but have lost track of how you're > > >> > getting on. > > > >> > Can you post an update and describe what the problem turned out > > >> > to be? > > > >> > Nial. > > > >> Quote from Actel website: "In March 2008, it was discovered that a > > >> potential advanced optimization could cause a logic gating of a global > > >> signal. > > >> This is fixed in Libero 8.3 released march 31 2008 > > >updating to 8.3 did not fix the problems, but I am getting closer > > >status: > > >in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi > > >slave from ext mcu) > > > >loadable LFSR in A1 domain > > >2:1 MUX for the selecting the load value > > >1 input of mux = const, loaded at powerup > > >2 input of mux connected to 24 bit shift register in A2 domain > > > >LFSR is loaded with constant at powerup, and loaded > > >with current value in spi shift register ONCE, after > > >that load the load enable signal is FULLY DISABLED > > >but when the there is data shifted in into the spi shift > > >register connected to the input mux of the LFSR load input > > >then some sequences of data make the LFSR content corrupt > > > >these sequences are REPEATABLE, that is not random! > > > As I understand it, the SPI register and the LFSR register are on different > > clock domains; with purely combinational logic (the mux, and the Load Enable) > > between them. > > > In Xilinx, as I understand it, if a 4-Lut transitions between one > > Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed > > not to glitch via a Load_Enable=True state. > > > I don't know Actel at all - is the same guarantee true there? > > > If not, I believe you need an intermediate register (just a simple pipeline > > register) clocked in the LFSR clock domain, to hold a copy of the SPI shift > > register. (This copy is subject to metastability, but with a tiny window of > > opportunity). Whereas now, you are exposed to the possibility of glitches > > derived from the SPI clock, and latched on the LFSR clock. > > > > That is the LFSR gets corrupted at certaing > > >values being visible on the load input via mux > > > ... or certain TRANSITIONS being visible on the load input? > > > IF the mux and the load enable logic are rolled into the same combinational > > cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values > > during a settling time window after the ... wrong clock. > > > >I already have forced the LFSR enable and mux select > > >to global clocks > > > I'm not sure that helps (it may reduce errors by an order of magnitude or more, > > but it leaves you open to the possibility above) > > > >of course the SPI clock and LFSR clocks are global > > >clocks as well > > > ... good... > > > just a guess but on the information given, it looks plausible to me. > > > - Brian > > Hi Brian, > > the story goes even more fascinating (or frustrating)... > > first about Actel - their Logic Cell is NOT LUT based, so the > LUT input transition glitches can not happen (no LUT!) but > actel cell has NO DEDICATED flip-flop, and flip flops are > configured out of logic, and have severe restrictions on > configuration and routing, FF with enable and clear are > made out 2 cells if CLR signal is not driven by global clock > sometimes 4 cells are used to make 1 single flip flop. > > the use of global clocks in actel, sometimes its not > "order of magnitude" difference but simple OK vs FAIL 100% issue > > case: 64 bit shift register (no enable just shift), clocked with CLEAN > clock at 4mhz > > work 100% when FPGA is almost empty (no matter what signal drivers > shift reg clock) > fails 100% when FPGA is >90% and shift clock is ruouted with local > connects > > PROVEN. this is also explanaibale, and actel has special appnote for > this (clock skew handling) > == > now to my clocking issue > > after taking a break I tried to eliminate things from the problem, so > I stopped shifting data > into the SPI shift register. this however made no difference, and when > i looked again > it was also explanaible as my test counter value was decoded in > external AR MCU > but the bytes holding the counter value did never get back into the > FPGA! > > so to summarize again: > > 1) ARM9 SW has counter, that is used to generate 8 byte encrypted > token > 2) those 8 bytes are going into FPGA over A1 parallel interface they > are written into dual port BRAM > 3) those 8 bytes are read by AVR over SPI interface > 4) AVR decodes those bytes, it also decodes the counter from step 1, > NO ERROR ever here > 5) AVR writes 3 bytes to FPGA SPI shift register > 6) AVR strobes to load LFSR, and set one time flag that prevents > further LFSR loads > 7) ARM9 sends packets in loop (encrypted counter) > > now, the counter value NEVER exist inside FPGA > the data passed via FPGA is not decoded there > the data passed via FPGA is not used by the logic responsible for the > load/enable of the LFSR > > still at some certain counter value, the LFSR does get corrupted!! > those values are repeatable, they are not random, that is each time > the ARM9 counter is > restarted then at exactly same counter values the LFSR is corrupted. > those values are however different for different PCB+bitstream > combinations > > 8) AVR puts FPGA into main mode > 9) ARM9 sends any packets any number of hours LFSR corruption no > longer happens! no single errror seen > > errors happen at [7] at const numbers of counter > error NEVER happen at [9] while streaming random data for hours.. > > so there is no different transitions on the load input of the LFSR at > all, still there is repeatable dependancy > on the data stream that only passes through FPGA > > eeee... [8] what happens there? > > well after main mode the AVR no longer collects data from FPGA and no > longer decrypts it. > but that should no have any influence as the decrypt result wasnt > passing into the FPGA anyway. > > there is one more difference, > after [8] the LFSR is enabled for 8 clocks lonfer for each packet from > A1 interface > > but the LFSR enable/load signals do not share any logic with any of > the data lines !! > > Ok, when found out that the counter data is not passing into the load > input at all, i did take a walk > and coffee break, and did write a list of options that can be tested, > list with 6 items, so will work > them out one by one > > my bet is that I need add delay on the LFSR enable signal, there is no > explanation why it should > be used as it is already a FF in the same clock domain as the LFSR > clock, but all other items > on my list of possible problems are even less likely (or harder to > test) > > Antti status: ALL ISSUES SOLVED I wonder how many guesses what the problem really was? :) I check one item from my list, what made no difference. luckuly i did not continue with my lists, as the real problem was not there anyway. sure, pure human error, there WAS dependancy on the data being pushed into FPGA there should not have been but it was, because some signal had wrong name. the same design error was already in intitial xilinx prototype a year ago but was never seen as it only happened 1:256 at startup while converting to Actel, i first reduced decode from 8 to 4 bits getting 1:16 errors and later to 3 bit getting 1:8 errors when I made my test with counter and got errors at some counter value, i did not print out the data bytes (8 byte encrypted) as I assumed them to be random but if i would have printed them out anyway, i would have seen at that any time when error happend 3 bits from 8 byte had constant value. that 3 bit value caused the LFSR enable to be of wrong duration. but, fixing it wasnt still so easy. After seeing the problem i fixed the it. then did make BIT file, and 2 different PCB boards did not work at all :( !? after that I managed to get the micro-SD card with the test program corrupted so badly that if insert that SD into card reader on Vista then Vista explorer HANGS (need power off !!) on XP it just cant access the card. ok, I get another sd card, put the test program onto it, and I see again the same errors ?? after really really fixing the VHDL I did rerun synplify and designer many times, to be sure they really generate new bit file, still the same error was there! guessed already? sure the Actel Flashprogramming tool had remembered wrong location for the bit file, so I used the wrong one. when the fixed bit file really got into the FPGA, then it worked as it was supposed Antti hope the thread wasnt so entirely boring :)Article: 130944
In my project the values are floating point. Since these floats take huge memory we have taken an SDRAM controller . These values are input to a custom peripheral which is linked to Microblaze through FSL. I have declared a float array which contains the input values.When i try to read these values using printf in C code then i only get the first value as correct output and rest all comes as some random symbols ( #, space etc).... Can anyone please help me guiding how can I handle floats in EDK ..........Any sort of related help is welcome........... :)Article: 130945
Hi, This is what your link returns; ¡Objeto no encontrado! El enlace requerido no ha sido localizado en este servidor. Si usted proporcionó el enlace de manera manual le solicitamos que por favor revise los datos e intentelo de nuevo. Por favor contacte con el webmaster en caso de que usted crea que existe un error en el servidor. Error 404 tokisworld.org Sun Apr 6 18:01:06 2008 Apache/2.0.53 (Linux/SUSE) -- Jaime Andres Aranguren C. SanJaaC Electronics Soluciones en DSP www.sanjaac.com "Thorsten Kiefer" <webmaster@nillakaes.de> escribió en el mensaje news:47f6653f$0$581$6e1ede2f@read.cnntp.org... > Hi, > I'm currently developing some examples for the > Spartan3 StarterKit from digilent. > Maybe this is interesting for newbies. > I know that they are not spectacular at the moment. > You can leave me a comment if you want. > > http://tokisworld.org/spartan3/ > > Regards > Thorsten > -- Posted via a free Usenet account from http://www.teranews.comArticle: 130946
> You do need to use the appropriate version for V4 with the fixes (which I > believe is any 9.X or later). I have version 9.2 and can't find any documentation on inferring FIFOs, synchronous or asynchronous, unless you consider instantiating a primitive such as FIFO18 and the like as inference. Brad Smallridge Ai VisionArticle: 130947
cpandya@yahoo.com writes: > If there is already a ready made solution for this then that will help > us. I've made a programmer that works over ethernet. I've been modifying it over the last few years to get the cost down. I will make it into a product if there is a demand for such a programmer. I can program fpga's (altera and xilinx), as well as spi devices, i2c, and microchip microcontrollers. It can also program several flash devices attached to other processors etc which have a jtag interface. I use it under linux, and the benefit is that you don't need a driver other than the network driver that is available with most (if not all) operating systems. Would there be any interest in such a programmer, or will most users want to stick with the programmers provided by the vendors? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 130948
Brad, Yes, sorry about that. Not all synthesis is equal when it comes to recognizing the IP blocks. And, a lot of it is too new to be supported today. I am aware of a lot of work by the XST folks, as well as by our partners, to recognize things like FIFO's, DSP48's, etc. automatically without having to specifically instantiate the blocks. I was concentrating on the known silicon V4 FIFO bug with the empty/full flags that was resolved by adding a small amount of external logic to get around the issue. The full hardware fix was implemented in V5, so that structure needed no special treatment. The V5 verification and characterization also learned many lessons from V4, and the overall release quality was improved a great deal. The FXT release just last week, is the finest ever (IMHO) by Xilinx, with now the complete solution platform released all at the same time. The three videos of the sophisticated pcbs that were built to showcase these apps are testament to the "whole enchilada" being ready to go on day one. At the ITRS TWG group meeting near Bonn last week (where I was), it was interesting to educate people that "it ain't your daddy's FPGA anymore..." The 65nm V5 family is only second to Intel's 65nm product offering in complexity and process sophistication (and perhaps we are, in fact first, since Hi-K is only in their 45nm line). They have dual core, we have dual core. They have neat IP, we have neat IP. They have some large die (with > 1 billion devices), and so do we. AustinArticle: 130949
austin wrote: > The 65nm V5 family is only second to Intel's 65nm product offering in > complexity and process sophistication (and perhaps we are, in fact > first, since Hi-K is only in their 45nm line). They have dual core, we > have dual core. They have neat IP, we have neat IP. They have some > large die (with > 1 billion devices), and so do we. The difference between Xilinx and Intel chips is that the decimal point for the price of the Xilinx parts is at the wrong position :-) I would like to use more FPGAs, but most of the time a fast CPU or microcontroller and maybe a small external FPGA, is cheaper and solves the problem, too. The PSoC concept from Cypress looks interesting: Lots of high-level analog and digital blocks, which can be connected at runtime and a fast CPU, all in a cheap and low power package: http://tinyurl.com/43qz49 Of course, you can't compare this to a Virtex, with which you can do high speed and parallel calculations, but for many products a small FPGA with a small CPU, some integrated analog components and standard interfaces, like I2C, USB, ethernet etc., would be nice. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
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