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
I need to buy a license for ISE Foundation to support some VIIPro work I'm doing. Would it make any difference to the price if I went via a distributor here in the UK or just bought online via the Xilinx web site? Anyone have any comments? TIA, Rog.Article: 92926
backhus wrote: > Hi folks, > I just stumbled over something funny: > > I usually write FSMs with registered outputs similar to this example: > > -- > -- $Id: > -- > ARCHITECTURE behavioral OF DEC_Controller_Modi IS > > TYPE DCM_state IS (Wait4Activation, Run_ECB, Run_CBC, Run_CFB, > Run_OFB, Run_CTR); > SIGNAL DCM_CurrentState : DCM_state; > SIGNAL DCM_NextState : DCM_state; > > BEGIN -- ARCHITECTURE behavioral > > -- purpose: StateRegister for DEC_Controller FSM > -- type : sequential > -- inputs : Clock, Reset, DCM_NextState > -- outputs: DCM_CurrentState > DCM_sync : PROCESS (Clock, Reset) IS > BEGIN -- PROCESS DCM_sync > IF Reset = '0' THEN -- asynchronous reset > (active low) > DCM_CurrentState <= Wait4Activation; > ELSIF Clock'event AND Clock = '1' THEN -- rising clock edge > DCM_CurrentState <= DCM_NextState; > END IF; > END PROCESS DCM_sync; > > -- purpose: Branch logic for DEC_Controller FSM > -- type : combinational > -- inputs : DCM_CurrentState, all > -- outputs: DCM_NextState > DCM_comb : PROCESS (DCM_CurrentState, ECB_Mode, CTR_Mode, > FeedbackSelect, AES_Ready, Phase1Active) IS > BEGIN -- PROCESS DCM_comb > CASE DCM_CurrentState IS > WHEN Wait4Activation => IF AES_Ready = '1' AND Phase1Active = '0' > THEN > IF ECB_Mode = '0' THEN > IF CTR_Mode = '0' THEN > CASE FeedbackSelect IS > WHEN "001" => DCM_NextState <= > Run_CBC; > WHEN "000" => DCM_NextState <= > Run_CFB; > WHEN "011" => DCM_NextState <= > Run_CFB; > WHEN "100" => DCM_NextState <= > Run_CFB; > WHEN "101" => DCM_NextState <= > Run_CFB; > WHEN "110" => DCM_NextState <= > Run_CFB; > WHEN "111" => DCM_NextState <= > Run_CFB; > WHEN "010" => DCM_NextState <= > Run_OFB; > WHEN OTHERS => NULL; > END CASE; > ELSE > DCM_NextState <= Run_CTR; > END IF; > ELSE > DCM_NextState <= Run_ECB; > END IF; > END IF; > WHEN Run_ECB => IF AES_Ready = '0' THEN > DCM_NextState <= Wait4Activation; > END IF; > WHEN Run_CBC => IF AES_Ready = '0' THEN > DCM_NextState <= Wait4Activation; > END IF; > WHEN Run_CFB => IF AES_Ready = '0' THEN > DCM_NextState <= Wait4Activation; > END IF; > WHEN Run_OFB => IF AES_Ready = '0' THEN > DCM_NextState <= Wait4Activation; > END IF; > WHEN Run_CTR => IF AES_Ready = '0' THEN > DCM_NextState <= Wait4Activation; > END IF; > --WHEN OTHERS => NULL; -- all states covered > END CASE; > END PROCESS DCM_comb; > > -- purpose: Registered Outputs for DEC_Controller FSM > -- type : sequential > -- inputs : Clock, Reset, all > -- outputs: all > DCM_regout : PROCESS (Clock, Reset) IS > BEGIN -- PROCESS DCM_regout > IF Reset = '1' THEN -- asynchronous reset (active > high) > Start_ECB <= '0'; > Start_CBC <= '0'; > Start_CFB <= '0'; > Start_OFB <= '0'; > Start_CTR <= '0'; > Phase2_3Active <= '0'; -- not active in Reset state > ELSIF Clock'event AND Clock = '1' THEN -- rising clock edge > Start_ECB <= '0'; > Start_CBC <= '0'; > Start_CFB <= '0'; > Start_OFB <= '0'; > Start_CTR <= '0'; > Phase2_3Active <= '1'; > CASE DCM_NextState IS > WHEN Wait4Activation => Phase2_3Active <= '0'; > WHEN Run_ECB => Start_ECB <= '1'; > WHEN Run_CBC => Start_CBC <= '1'; > WHEN Run_CFB => Start_CFB <= '1'; > WHEN Run_OFB => Start_OFB <= '1'; > WHEN Run_CTR => Start_CTR <= '1'; > -- WHEN OTHERS => NULL; -- all states > covered > END CASE; > END IF; > END PROCESS DCM_regout; > > END ARCHITECTURE behavioral; > > --------------------------------------------------------------------- > > While ISE creates a nice little FSM, Precision RTL and Synopsys Design > Analyser drop in a bunch of latches for the DCM_NextState signal bits. > Well, from an isolated point of view they are right. My case statement > lacks default values (the "when others" has been commented out, because > Precision gives a warning, that all brances are covered). > > So, what makes me wonder is that both expensive tools create > latch-loaded garbage while "cheap little" ISE synthesizes as expected by > me. Besides the ugly option of writing defaults into all when-brances, > is there any solution that pushes precision and/or synopsys dc to a > better synthesis? A single line with the default, right before the case statement in DCM_comb, should do it: DCM_NextState <= DCM_CurrentState; Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.comArticle: 92927
I just made the mistake of spending a month designing a board for the Virtex-4 FX without first checking availability. Xilinx has been talking about the part for nearly a year, there are dev boards all over the place, surely there must be silicon available, right? Now both Avnet and NuHo are telling me that Xilinx is having "yield problems" and it could be as late as June of 06 before they're shipping silicon. Has anyone had any luck finding these parts? I'm just looking for a couple samples to finish my thesis project, and it would be nice to not have to spend another month redesigning this hardware... Thanks, ...EricArticle: 92928
"Roger" <enquiries@rwconcepts.co.uk> schrieb im Newsbeitrag news:Ktimf.6307$64.44@newsfe2-win.ntli.net... >I need to buy a license for ISE Foundation to support some VIIPro work I'm >doing. Would it make any difference to the price if I went via a >distributor here in the UK or just bought online via the Xilinx web site? >Anyone have any comments? > > TIA, > > Rog. > check out development board package deals, sometimes it makes sense to buy some dev board with bundled ISE (or EDK) as the board price will then be haevily reduced compared to board+ISE price if purchased separatly. anttiArticle: 92929
<acetylcholinerd@gmail.com> schrieb im Newsbeitrag news:1134147191.930994.183170@z14g2000cwz.googlegroups.com... >I just made the mistake of spending a month designing a board for the > Virtex-4 FX without first checking availability. Xilinx has been > talking about the part for nearly a year, there are dev boards all over > the place, surely there must be silicon available, right? Now both > Avnet and NuHo are telling me that Xilinx is having "yield problems" > and it could be as late as June of 06 before they're shipping silicon. > Has anyone had any luck finding these parts? I'm just looking for a > couple samples to finish my thesis project, and it would be nice to not > have to spend another month redesigning this hardware... > > Thanks, > ...Eric > scary business we are shipping products with FX12 on board and we are just about to re-order parts, I know that all FX MGT production silicon is not be expected before Q3, but I did not assume any issues with FX12 part, as it was available looong time ago. it could be that disties dont wanna have ES silicon in stock and they are using standard worst case lead time, so thats why it looks so bad for you. I bet FX12-ES in sample quantity should be obtainable. AnttiArticle: 92930
I'm very interested in this project. I usually do High-Speed PCB design and FPGA programming at work so I think this board shouldn't be a problem for me. Anyway I've got a few questions for you: - have you got full schematics of the original designs or this has to be reverse-engineered? - how many pieces of these boards do you need? - those 500$ are meant for each design or for each delivered PCB? Best regards, Vito a c i d o c i n i c o (at) l i b e r o (dot) i tArticle: 92931
Antti, Yes you are correct, there are no issues with FX12. Austin Antti Lukats wrote: > <acetylcholinerd@gmail.com> schrieb im Newsbeitrag > news:1134147191.930994.183170@z14g2000cwz.googlegroups.com... > >>I just made the mistake of spending a month designing a board for the >>Virtex-4 FX without first checking availability. Xilinx has been >>talking about the part for nearly a year, there are dev boards all over >>the place, surely there must be silicon available, right? Now both >>Avnet and NuHo are telling me that Xilinx is having "yield problems" >>and it could be as late as June of 06 before they're shipping silicon. >>Has anyone had any luck finding these parts? I'm just looking for a >>couple samples to finish my thesis project, and it would be nice to not >>have to spend another month redesigning this hardware... >> >>Thanks, >> ...Eric >> > > > scary business we are shipping products with FX12 on board and we are just > about to re-order parts, I know that all FX MGT production silicon is not be > expected before Q3, but I did not assume any issues with FX12 part, as it > was available looong time ago. > > it could be that disties dont wanna have ES silicon in stock and they are > using standard worst case lead time, so thats why it looks so bad for you. I > bet FX12-ES in sample quantity should be obtainable. > > Antti > >Article: 92932
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:dnce6h$f694@xco-news.xilinx.com... > Antti, > > Yes you are correct, there are no issues with FX12. > > Austin HUH, thanks for quick clarification! http://www.hydraxc.com there isnothing muchonline, but the FX12 based modules are actually shipping now, so knowing that the FX12 supply is ok is quite a bit important anttiArticle: 92933
Thomas, what's wrong with CoreGen? You can of course design your own FIFO controller, but it is tricky. The two address counters live in different clock domains, and any synchronization across the domain border must be done with Gray-codes values. But for indicating ALMOST FULL, ALMOST EMPTY, etc. you need binary values. Therefore there are code translations going on that require some expertise, especially when the clock rates are high. You can contact me for some individual advice...(even in German) Peter Alfke, Xilinx Applications ============= Thomas Entner wrote: > A need an asynch. FIFO for a Spartan 3E-design, without CoreGen. On the > Xilinx-web-page I only found XAPP258, which I cannot use as I need a > "level-indication" for both clock-domains. Is it possible that something > basic as this is not available for free, or have I just looked in the wrong > places? Do I need to implement this on my own? > > Thomas > > www.entner-electronics.comArticle: 92934
> >> I must develop a system with lots of I/O, about 180-190. My chief don't >> want use BGA (fg320), but pq208... >> so I thought to connect 2 fpga pq208. > >> I think it'is bad... but there are other chances? > >> Otherwise does exist a BGA adapter for fg320 package to change it into a >> pq320? > >Why not use a FPGA module like the Zefant Modules? (www.zefant.de)? I have one of those Zefant S3-1000 boards + Baseboard , it's an excellent combination. There is even 47 pcs. 5v tolerant CPLD pins in addition to the FPGA pins. CarstenArticle: 92935
Hi Peter, thanks for your answer. The only thing wrong with core-generator is that it's not included in the web pack ;-) In the meantime I have bitten the bullet and implemented the FIFO myself. (I am well aware of those clock-domain crossing issues... and I do not need a complete full or complete empty-flag) It's already running in hardware. The only thing missing is a timing-constraint to limit the skew of the gray-code-bits, when it passes from one clock-domain to the other. Or can I rely on ISE that the skew/delay of this path (from register to register, no logic between) will always be very small, as it is in the moment? BTW: How is this solved by the core-gen? Does it automatically apply these constraints? Thomas "Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:1134150407.670912.197670@f14g2000cwb.googlegroups.com... > Thomas, what's wrong with CoreGen? > You can of course design your own FIFO controller, but it is tricky. > The two address counters live in different clock domains, and any > synchronization across the domain border must be done with Gray-codes > values. But for indicating ALMOST FULL, ALMOST EMPTY, etc. you need > binary values. Therefore there are code translations going on that > require some expertise, especially when the clock rates are high. > You can contact me for some individual advice...(even in German) > Peter Alfke, Xilinx Applications > > ============= > Thomas Entner wrote: >> A need an asynch. FIFO for a Spartan 3E-design, without CoreGen. On the >> Xilinx-web-page I only found XAPP258, which I cannot use as I need a >> "level-indication" for both clock-domains. Is it possible that something >> basic as this is not available for free, or have I just looked in the >> wrong >> places? Do I need to implement this on my own? >> >> Thomas >> >> www.entner-electronics.com >Article: 92936
If you go the distributor they may offer a bundle with other items depending on your circumstances and project. If you are likely to want anything else then it may be the better path. Certainly should not be any more expensive than the website which tends to book pricing. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Roger" <enquiries@rwconcepts.co.uk> wrote in message news:Ktimf.6307$64.44@newsfe2-win.ntli.net... >I need to buy a license for ISE Foundation to support some VIIPro work I'm >doing. Would it make any difference to the price if I went via a >distributor here in the UK or just bought online via the Xilinx web site? >Anyone have any comments? > > TIA, > > Rog. >Article: 92937
Yes, impact send a command to stop the FPGA. One thing you can do it to use the SelectMap interface or send the bitstream to the jtag without using Impact. It is not very difficult to make a program in C to program the FPGA using the JTAG. Javier On 9 Dec 2005 08:28:47 -0800, "Denaice" <dgalerin@gmail.com> wrote: >Well, for the moment, I'm not reconfiguring through ICAP with a PPC or >Microblaze. I'm only trying to reconfigure in JTAG by the remote PC, >but it seems - obviously - that the FPGA pauses when reconfiguring >(because in my design, the leds which, should continue to blink, are >shut down). > >I don't know....Article: 92938
"Thomas Entner" <aon.912710880@aon.at> schrieb im Newsbeitrag news:4399c8c0$0$15674$91cee783@newsreader01.highway.telekom.at... > Hi Peter, > > thanks for your answer. The only thing wrong with core-generator is that > it's not included in the web pack ;-) > > In the meantime I have bitten the bullet and implemented the FIFO myself. > (I am well aware of those clock-domain crossing issues... and I do not > need a complete full or complete empty-flag) It's already running in > hardware. > > The only thing missing is a timing-constraint to limit the skew of the > gray-code-bits, when it passes from one clock-domain to the other. Or can > I rely on ISE that the skew/delay of this path (from register to register, > no logic between) will always be very small, as it is in the moment? BTW: > How is this solved by the core-gen? Does it automatically apply these > constraints? > > Thomas > Hi Thomas, the fromto inside FPGA (no logic levels) can be as much as >10ns !! if it passes local routing accross chip so if very small delays are needed the the P&R must know it AnttiArticle: 92939
Hi, A thought cross my mind ... I've been working much on Virtex4 lately and getting fast (~300-350 Mhz) logic for the datapath isn't really hard. But making the control stuff go that fast is a whole lot more tricky, just a 10 bits comparator becomes "a lot" at that speed ... and some control signals have high fanout and that brings the net delay in the 1 - 1.5 ns range which is half of the period ... So what if every now and then in the FPGA fabric, there was a small cluster of like 1 CLB with "Super LUTs" that would have a whole lot faster logic (but no special func like SRL and distributed ram) and "bigger" drivers to charge/dischare the net faster to propagate the controls. Maybe it's un-feasible for some reason, it's just a thought ... SylvainArticle: 92940
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag news:4399cf94$0$9070$ba620e4c@news.skynet.be... > Hi, > > A thought cross my mind ... > > I've been working much on Virtex4 lately and getting fast (~300-350 Mhz) > logic for the datapath isn't really hard. But making the control stuff > go that fast is a whole lot more tricky, just a 10 bits comparator > becomes "a lot" at that speed ... and some control signals have high > fanout and that brings the net delay in the 1 - 1.5 ns range which is > half of the period ... > > So what if every now and then in the FPGA fabric, there was a small > cluster of like 1 CLB with "Super LUTs" that would have a whole lot > faster logic (but no special func like SRL and distributed ram) and > "bigger" drivers to charge/dischare the net faster to propagate the > controls. > > Maybe it's un-feasible for some reason, it's just a thought ... > > > Sylvain I guess altera would claim they have it in the stratix ALm AL (Antti Lukats)Article: 92941
Hi Antti, I had expected that :-( Let's say, my critical FF's are: signal read_cnt_gray: unsigned(8 downto 0) := (others => '0'); -- in read-clock-domain and signal read_cnt_gray_pre_sync_wr: unsigned(8 downto 0) := (others => -- in write-clock-domain is there a way to add the timing-constraint in the VHDL-source (so that I can easily reuse the module for different designs, without always editing the ucf-file, etc.)? Thomas www.entner-electronics.com > Hi Thomas, > > the fromto inside FPGA (no logic levels) can be as much as >10ns !! > if it passes local routing accross chip so if very small delays are needed > the the P&R must know it > > AnttiArticle: 92942
Yeah, If there's no issues with FX12, meaning no important design errors (apart from the system manager which was cancelled..), yield problems etc, then if sample quantity is all that's available, it can only be because all devices are being sold to big customers. I guess the 80 nm factories in the world are being overloaded with work on producing new 80 nm chips from different companies and I can think of one company that is having a lot of new chip revisions done these days... Finn "Antti Lukats" <antti@openchip.org> skrev i en meddelelse news:dncf71$t30$01$1@news.t-online.com... > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:dnce6h$f694@xco-news.xilinx.com... >> Antti, >> >> Yes you are correct, there are no issues with FX12. >> >> Austin > > HUH, thanks for quick clarification! > > http://www.hydraxc.com > > there isnothing muchonline, but the FX12 based modules are actually > shipping now, so knowing that the FX12 supply is ok is quite a bit > important > > antti > > >Article: 92943
Hi, I know tha some EDA tools provide encryption feature to protect confidentiality of the HDL source code but how do we do this in ModelSim/FPGA Adv or in Xilinx ISE? So that I can provide an encrypted source code to someone and yet it works as real RTL desription. Please suggest. Thanks, FahadArticle: 92944
I am looking for further documentation for the VGA connections on the ML40x boards. ug82 says that there is 50MHz chips on the ML401s and 140MHz chips on the ML402s and ML403s. The ML403's FX12 has reduced pins and only five bits per color. I suppose the best VGA would therefore come from the ML402s. From the schematic I see that the upper five bits per color are attached to Bank6 and the lower three bits per color are attached to Bank9. There is a difference in drive voltage between the two banks, does the VGA chip care? Is there anyway to compensate with different drive currents. I have a few UCF files with different stories. What does contingent mean in a UCF file? Is there any other documents other than the Xilinx schematics and the VGA manufacturers data sheets? Brad Smallridge aivision.comArticle: 92945
"Brad Smallridge" <bradsmallridge@dslextreme.com> schrieb im Newsbeitrag news:11pjnhdoufq890a@corp.supernews.com... >I am looking for further documentation for the VGA connections on the ML40x >boards. > > ug82 says that there is 50MHz chips on the ML401s and 140MHz chips on the > ML402s and ML403s. The ML403's FX12 has reduced pins and only five bits > per color. I suppose the best VGA would therefore come from the ML402s. > > From the schematic I see that the upper five bits per color are attached > to Bank6 and the lower three bits per color are attached to Bank9. There > is a difference in drive voltage between the two banks, does the VGA chip > care? Is there anyway to compensate with different drive currents. > > I have a few UCF files with different stories. What does contingent mean > in a UCF file? > > Is there any other documents other than the Xilinx schematics and the VGA > manufacturers data sheets? > > Brad Smallridge > aivision.com > the video dacs clock the data so as long as setup and hold times are met the different banks for the DAC outputs should not be an issue. so the vga chip does not care. AnttiArticle: 92946
>>So what if every now and then in the FPGA fabric, there was a small >>cluster of like 1 CLB with "Super LUTs" that would have a whole lot >>faster logic (but no special func like SRL and distributed ram) and >>"bigger" drivers to charge/dischare the net faster to propagate the >>controls. >> >>Maybe it's un-feasible for some reason, it's just a thought ... >> >> >>Sylvain > > > I guess altera would claim they have it in the stratix ALm > AL > (Antti Lukats) They do ? I'm gonna check that out ... SylvainArticle: 92947
"Sylvain Munaut" <com.246tNt@tnt> schrieb im Newsbeitrag news:4399e34b$0$10953$ba620e4c@news.skynet.be... > >>>So what if every now and then in the FPGA fabric, there was a small >>>cluster of like 1 CLB with "Super LUTs" that would have a whole lot >>>faster logic (but no special func like SRL and distributed ram) and >>>"bigger" drivers to charge/dischare the net faster to propagate the >>>controls. >>> >>>Maybe it's un-feasible for some reason, it's just a thought ... >>> >>> >>>Sylvain >> >> >> I guess altera would claim they have it in the stratix ALm >> AL >> (Antti Lukats) > > They do ? > I'm gonna check that out ... > > > Sylvain not quite so but they claim to have 7-input lut capabilities for better logic opt. anttiArticle: 92948
Something like NET *read_cnt_gray* MAXDELAY=3ns; perhaps? "Thomas Entner" <aon.912710880@aon.at> wrote in message news:4399d29c$0$22256$91cee783@newsreader02.highway.telekom.at... > Hi Antti, > > I had expected that :-( > > Let's say, my critical FF's are: > > signal read_cnt_gray: unsigned(8 downto 0) := (others => > -- in read-clock-domain > and > signal read_cnt_gray_pre_sync_wr: unsigned(8 downto 0) := (others => -- in > write-clock-domain > > is there a way to add the timing-constraint in the VHDL-source (so that I > can easily reuse the module for different designs, without always editing > the ucf-file, etc.)? > > Thomas > > www.entner-electronics.com > >> Hi Thomas, >> >> the fromto inside FPGA (no logic levels) can be as much as >10ns !! >> if it passes local routing accross chip so if very small delays are >> needed >> the the P&R must know it >> >> Antti > >Article: 92949
Thomas, it only depends on your clock speed. Even the domain-crossing registers have a whole clock tick to make up their mind. With Gray-coded values, you already assume that you might unavoidably clock in a mixture of the older and the newer value, but that does not matter with Gray codes. It's either the old or the new value, never anything else. In other words, you don't have to be super-fast, as long as you meet the required (synchronous) timing constraints, determined by the clock rates. Peter Alfke, Xilinx Applications.
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