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
"Eli Bendersky" <eliben@gmail.com> wrote in message news:1179737183.440448.61650@x18g2000prd.googlegroups.com... > > What are your thoughts ? > > Thanks in advance > Hi Eli, You don't need my thoughts, especially at this early hour! Luckily, there are plenty of other thoughts easily available. :-) Google:- reset synchronous site:xilinx.com http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_smart_reset HTH, Syms. p.s. We've been over this many times on this newsgroup before. You'd do well to trawl the archive.Article: 119476
"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message news:f2rh0u$kh6$1@newsserver.cilea.it... > In news:XX24i.1173$u56.485@newssvr22.news.prodigy.net timestamped Sun, > 20 May 2007 17:19:47 -0400, "KJ" <kkjennings@sbcglobal.net> posted: > "[..] > > Just to clarify: does std_ulogic have a huge disadvantage in contrast > to std_logic when modelling combinatorial feedback? > No disadvantages that I can think of. <snip> I understand and may agree with this point but I disagree with the > particular example as being an issue of skill... I would classify this > as more of an issue of whether the designers know what their tools do. > Knowledge of what the tools do and how best to use those tools is part of what I would classify as 'skill', others may feel differently. KJArticle: 119477
On May 21, 1:52 pm, "J.Ram" <jrgod...@gmail.com> wrote: > Hi all, > I developed a design in which i need a master clock of 90Mhz, so > during synthesis max. freq obtained is 56Mhz and timing is met for > global clock of 50Mhz, but timing are not met for 90Mhz. > but design is working on board for 90Mhz clcock. > In design all lower level module are working above 100 Mhz, but in top > module after integarting sub blocks it works around 56 Mhz in > synthesis and working at 90Mhz on board. > so please tell me what is wrong with this design. > Regards > J.Ram It may be because u are not yet applied any test vectors which will violate the 50MHz+ timings..... That may be the one reason why it is working on the board....Article: 119478
In news:464B9365.9040105@itee.uq.edu.au timestamped Thu, 17 May 2007 09:27:33 +1000, John Williams <jwilliams@itee.uq.edu.au> posted: "[..] Are you aware of the Reconfigurable Scalable Computing (RSC) project being run out of NASA Langley? A few web references below, but feel free to contact me directly if you'd like more info. http://linuxdevices.com/news/NS9415221766.html http://www.klabs.org/mapld05/presento/130_hodson_p.ppt http://www.klabs.org/mapld05/presento/125_somervill_p.ppt http://www.klabs.org/mapld05/presento/1001_williams_p.ppt Regards, John" Dear Dr. Williams, I note that the term "Bus" appears twice on WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#299,9,Reconfigurable Processing Module in contrast to the term "Scalable Network" on WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#268,4,Scalable Architecture Is the cache mentioned on WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features suitable for realtime use? "Xilinx logic is triplicated" on WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features is not detailed enough to show what risks your form of triplication is susceptible to and resilient to. On WWW.Klabs.org/mapld05/presento/125 somervill p.ppt#281,10,Embedded Processing it is written: "Design mitigated with XTMR tool (or manually)". What drives your choice for the XTMR tool or manual error detection and correction? However, I note from WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#266,11,MicroBlaze, Linux and RSC that your reconfigurable systems for NASA are not intended for spacecraft survivability, so protection against errors might not be very important for you. On WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#285,16,MicroBlaze Multiprocessing it is claimed "We can put about 8 CPUs in an FPGA" so what is the 33% utilization "of FIFO16/RAM16s" on WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#260,9,MicroBlaze for? Thanks, Colin Paul GlosterArticle: 119479
On 19 May 2007 18:58:35 -0700, Weng Tianxiang wrote: >This time I don't agree with your opinion. > >What I do is to print out all related waveforms I am interested in and >using tab is to make me easier to manually check if the waveforms are >right so that a software can be used later to check the waveforms >without 1 clock after another to manually check waveforms. Ah - you are using tabs to create a tab-separated file for Excel or some similar software? If so, then I'm sorry - yes - that's OK. I still think tabs are a crazy way to create human-readable layouts, because different editors and terminals may handle tabs in different ways. It can get *very* ugly. > ht works for tab in VHDL. Indeed. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 119480
Un bel giorno J.Ram digiṭ: > but timing are not met for 90Mhz. > but design is working on board for 90Mhz clcock. As far as I know, the timing extimations in ISE are made assuming always the worst case scenario (worst temperatures, worst limit of each specified parameter, etc). They represent a "lower performance limit", but for the actual speed limit I've noticed a lot of difference between the extimation and the reality, especially in blocks with few gates. For example in a SpartanII design I have a 8-bit gray counter incremented by an external clock that in reality exceeds 250 MHz of performance, while the timing extimations suggest a maximum frequency that barely exceeds 100 MHz. -- emboliaschizoide.splinder.comArticle: 119481
"J.Ram" <jrgodara@gmail.com> wrote in message news:1179737574.032115.244360@a26g2000pre.googlegroups.com... > Hi all, > I developed a design in which i need a master clock of 90Mhz, so > during synthesis max. freq obtained is 56Mhz and timing is met for > global clock of 50Mhz, but timing are not met for 90Mhz. > but design is working on board for 90Mhz clcock. > In design all lower level module are working above 100 Mhz, but in top > module after integarting sub blocks it works around 56 Mhz in > synthesis and working at 90Mhz on board. > so please tell me what is wrong with this design. > Regards > J.Ram What is wrong is your expectation that based on a sample of one board that works at 90 MHz, that all boards over all rated temperature conditions over all possible input conditions will also work at that speed. It's not at all unusual to expect that a single board in a lab environment might happen to work at ~50% over the speed computed by the timing analyzer. Try building thousands of such boards and put them in the extreme rated temperature conditions and give them the most stressful input pattern and see how many of those boards still work. What you'll likely find is a lot of fallout...but again you might have a few survivors. KJArticle: 119482
Thanks for the input Peter. I have started looking into the pointers that you have provided. Just to make this discussion complete, I would like to record one further observation that I made. The 2 MHz clock is driving the FPGA ( as I had previously mentioned ) as well as a codec on the board. When the codec power supply is switched off , then the FPGA is generating pulses at pulses at 500 ns width ( 1 clock period of the 2MHz clock) . But as soon as the codec is turned on , the FPGA pulses are now of 250 ns width. In both the cases though , the external clock frequency remains 2.048 MHz. Uptil now my ucf setting for the clock pin input was as follows NET TDM_CLK_pin LOC = "B16"; NET TDM_CLK_pin IOSTANDARD = LVCMOS25; I will try to use any of the IOB settings to terminate the clock properly. If I can solve this problem, I will report it in this discussion. Thanks once again Venu Peter Alfke wrote: > Venu, > I am sure that your problem is caused by poor signal integrity at the > clock input to the FPGA. There may be overshoot, undershoot and > ringing, which causes the FPGA to interpret the falling clock edge as > another rising clock edge. > Try to clean up the clock signal, terminate it properly. > 2 MHz is a very low clock frequency, and it might have a slow rise/ > fall time, which might be another source of double-triggering caused > by noise during the transition. > Peter Alfke, from home. > > > On May 19, 2:35 am, Venu <get2v...@gmail.com> wrote: > > Hi People, > > > > I am attempting to interface the Xilinx Virtex - II Pro FPGA with a > > quad channel codec. > > > > I am using XC2VP30-FF896 FPGA on the Xilinx University Program > > Development Board.I had applied a 2.048MHz TDM clock to the FPGA pin > > B16, which is the GCLK6S ( Global Clock Input). > > > > My problem is that by the time this clock reaches my IP on the OPB > > Bus , its frequency doubles!! I have confirmed this by checking > > pulses generated on the basis of this clock, on a Digital > > Oscilloscope. > > > > I have confirmed that I have not instantiated a DCM in the external > > clock path . The resource utilisation shows that the system uses only > > 1 DCM , which is attached to the sys_clk_s. > > > > For now , to make my system work , i have divided the clock frequency > > inside my IP and then applied it to the individual block. But the > > confusion of why this exactly happened still remains. > > > > Thanks > > VenuArticle: 119483
EHLO (o; I tried several weeks ago to contact EBV Switzerland where to get EP1C and EP2C devices in smaller quantities than their 60/90 package size...but never got any feedback... Also their website gives no results when doing inventory search nor their contact form works anymore...looks really borked to me (o; So...any experience with ordering devices online from Altera directly? Was so much nicer support at EBV Finland back then (o; cheers rickArticle: 119484
Richard Klingler <me@aol.com> wrote: > EHLO (o; > I tried several weeks ago to contact EBV Switzerland where to get > EP1C and EP2C devices in smaller quantities than their 60/90 > package size...but never got any feedback... > Also their website gives no results when doing inventory search > nor their contact form works anymore...looks really borked to me (o; > So...any experience with ordering devices online from Altera > directly? > Was so much nicer support at EBV Finland back then (o; Consider to buy at Digikey. At lot of EP1 parts are listed as stock I odered about 16 different part numbers, including Xilinx XC3S500E on Friday evening and have them alrteady on the desk. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 119485
Dear Rick What was the problem getting 1C/2C at EBV in Switzerland ? Call me so we can discuss this. Regards Daniel +41447456161 daniel.studer@ebv.com On 21 mei, 13:46, Richard Klingler <m...@aol.com> wrote: > EHLO (o; > > I tried several weeks ago to contact EBV Switzerland where to get > EP1C and EP2C devices in smaller quantities than their 60/90 > package size...but never got any feedback... > > Also their website gives no results when doing inventory search > nor their contact form works anymore...looks really borked to me (o; > > So...any experience with ordering devices online from Altera > directly? > > Was so much nicer support at EBV Finland back then (o; > > cheers > rickArticle: 119486
On May 21, 4:19 am, Anson.Stugg...@gmail.com wrote: > Hello, > > I'm trying to learn VHDL and here I'm adding a parity bit to Ben > Cohen's UART Receiver. RxReg(9) is incoming parity bit from > transmitter side. A 0 output at Parity_err means no parity error > detected and otherwise. The receiver has to match the incoming parity > bit with its own parity bit which is calculated using XOR of its data > byte, RxReg(8 downto 0). My statement below is giving me a full byte > delay because my control statements for the parity check. I think it's > because of the process statement, but that's all I can think of now. > > can someone let me know how to fix this? > > Thanks, > AS > ------------------------------------------------------------------------------- > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > ------------------------------------------------------------------------------- > -- > -- Project : ATEP > -- File name : uartrx.vhd > -- Title : UART Receiver > -- Description : UART receiver selection > -- > ------------------------------------------------------------------------------- > -- Revisions : > -- Date Author Revision > Comments > -- Sat Oct 30 10:05:49 1994 cohen Rev A Creation > ------------------------------------------------------------------------------- > entity UartRx_Nty is > port (Clk16xT : in std_logic; -- 16 of these clocks per > bit > ResetF : in std_logic; > Serial_InT : in std_logic; > DataRdyT : out boolean; > DataOuT : out std_logic_Vector(7 downto 0); > Parity_err : out std_logic; -- Parity Error Output > BitClkT : out std_logic); -- same speed clock as Tx > end UartRx_Nty; > > architecture UartRx_Beh of UartRx_Nty is > subtype Int0to15_Typ is integer range 0 to 15; > constant RxInit_c : std_logic_Vector(10 downto 0) := "11111111111"; > signal RxReg_s : std_logic_Vector(10 downto 0); -- the receive > register > signal Count16_s : Int0to15_Typ; -- for divide by 16 > signal RxMT_s : boolean; -- Receive register empty > signal RxIn_s : std_logic; -- registered > serial input > signal Parity_Reg : std_logic; > > begin -- UartRx_Beh > > ----------------------------------------------------------------------------- > -- Process: Xmit_Lbl > -- Purpose: Models the receive portion of a UART. > -- Operation is as follows: > -- . All operations occur on rising edge of Clk16xT. > -- . Clk16xT runs 16x the bit clock rate > -- . If ResetF = '0' then > -- RxReg_s is reset to "11111111111". > -- Count_s is reset to 0. > -- . If (RxMT_s and RxIn_s = '0') then > -- Start of new byte > -- . If Count16_s = 7 and not RxMT_s then -- mid > clock > -- Sample here where bit most stable > -- RxReg_s <= RxIn_s & RxReg_s(9 downto 1); > -- . Entire byte received when > -- not RxMT_s and RxReg_s(9) = '1' and RxReg_s(0) = > '0' > -- > > ----------------------------------------------------------------------------- > Rx_Lbl : process > > begin -- process Rx_Lbl > wait until Clk16xT'event and Clk16xT = '1'; > -- Clock serial input into RxIn_s > RxIn_s <= Serial_InT; > > -- reset > if (ResetF = '0') then > Count16_s <= 0; -- reset divide by 16 > counter > RxMT_s <= true; -- no message starting; > idle > RxReg_s <= RxInit_c; > > -- new bit start > elsif (RxMT_s and RxIn_s = '0') then > Count16_s <= 0; -- reset divide by 16 > counter > RxMT_s <= false; -- new message starting > RxReg_s <= RxInit_c; > > -- If in a receive transaction mode > -- if @ mid bit clock then clock data into register > elsif Count16_s = 7 and not RxMT_s then -- mid clock > RxReg_s <= RxIn_s & RxReg_s(10 downto 1); > Count16_s <= Count16_s + 1; > > -- if @ 16X clock rollover > elsif Count16_s = 15 then > Count16_s <= 0; > > -- Normal count16 counter increment > else > Count16_s <= Count16_s + 1; > end if; > > -------------------------------------------------------------Parity > Check Control > Statement--------------------------------------------------------- > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- Check if a data word is received > if not RxMT_s and RxReg_s(10) = '1' and RxReg_s(0) = '0' then > Parity_reg = ((RxReg_s(1) xor RxReg_s(2)) xor (RxReg_s(3) xor > RxReg_s(4))) xor ((RxReg_s(5) xor RxReg_s(6)) xor (RxReg_s(7) xor > RxReg_s(8))) > > if Parity_reg /= RxReg_s(9) then > Parity_err <= '1'; > else > Parity_err <= '0'; > end if; > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > DataRdyT <= true; > RxMT_s <= true; > else > DataRdyT <= false; > end if; > end process Rx_Lbl; > > ------------------------------------------------------------------------------- > -- Concurrent signal assignment for BitClkT and DataOut > ------------------------------------------------------------------------------- > > BitClkT <= '1' when Count16_s = 10 > else '0'; > > DataOuT <= RxReg_s(8 downto 1); > > end UartRx_Beh; The point of sending the parity bit at the end of a transmission is that you can compute the parity as you transmit, one bit at a time. Regardless of the parity bit location, you can do the same for receiving because as far as parity checking is concerned, the parity bit is just another input to your XOR function. There is no need to calculate parity on the 8-bit parallel data. You can receive "running" parity one bit at a time as you fill the shift register, then your parity check will be complete at the same time you transfer data to the parallel register. Parity checking is effectively just a "T" flip-flop that gets cleared between data words. The T input is attached to the incoming data. Clock is enabled at the same time as your shift register. When all bits including parity have been shifted in, the Q of the flip-flop should have a constant value which only depends on the type of parity (even or odd). By the way, the reason you're getting a delay in your code is that the check is inside the clocked process that loads the parity register. So the data on the output of the parity register at the time the process runs is from the previous word. If you wanted to use a parallel method of parity checking, you either need to calculate the parity in a separate non-clocked process or use a variable for Parity_Reg so the parity check is executed in the same cycle. HTH, GaborArticle: 119487
On May 21, 11:00 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Eli Bendersky" <eli...@gmail.com> wrote in message > > news:1179737183.440448.61650@x18g2000prd.googlegroups.com... > > > What are your thoughts ? > > > Thanks in advance > > Hi Eli, > You don't need my thoughts, especially at this early hour! Luckily, there > are plenty of other thoughts easily available. :-) > > Google:- > reset synchronous site:xilinx.com > > http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_smart... > > HTH, Syms. > > p.s. We've been over this many times on this newsgroup before. You'd do well > to trawl the archive. I think you misunderstood my question. I am not asking about a synchronous vs. asynchronous reset and about reset release. I'm asking about filtering potential noise that may be present on the reset_n line on the board that goes between the voltage supervisor and the FPGA. EliArticle: 119488
On May 21, 4:20 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "J.Ram" <jrgod...@gmail.com> wrote in message > > news:1179737574.032115.244360@a26g2000pre.googlegroups.com... > > > Hi all, > > I developed a design in which i need a master clock of 90Mhz, so > > during synthesis max. freq obtained is 56Mhz and timing is met for > > global clock of 50Mhz, but timing are not met for 90Mhz. > > but design is working on board for 90Mhz clcock. > > In design all lower level module are working above 100 Mhz, but in top > > module after integarting sub blocks it works around 56 Mhz in > > synthesis and working at 90Mhz on board. > > so please tell me what is wrong with this design. > > Regards > > J.Ram > > What is wrong is your expectation that based on a sample of one board that > works at 90 MHz, that all boards over all rated temperature conditions over > all possible input conditions will also work at that speed. > > It's not at all unusual to expect that a single board in a lab environment > might happen to work at ~50% over the speed computed by the timing analyzer. > Try building thousands of such boards and put them in the extreme rated > temperature conditions and give them the most stressful input pattern and > see how many of those boards still work. What you'll likely find is a lot > of fallout...but again you might have a few survivors. > > KJ Can we say that is ~50%....Article: 119489
J.Ram wrote: > Hi all, > I developed a design in which i need a master clock of 90Mhz, so > during synthesis max. freq obtained is 56Mhz and timing is met for > global clock of 50Mhz, but timing are not met for 90Mhz. > but design is working on board for 90Mhz clcock. > In design all lower level module are working above 100 Mhz, but in top > module after integarting sub blocks it works around 56 Mhz in > synthesis and working at 90Mhz on board. > so please tell me what is wrong with this design. > Regards > J.Ram It's not the *entire* chip that's limited to 56 MHz. Use the Xilinx Timing Analyzer to determine which paths are failing timing. This will both inform you as to where you might see the failure show up (e.g., if it's an accumulator to a register read by software, you'll only know it's a problem if you know what the count should be when/if you read it). It will also give you an idea of where to recode your RTL to achieve 100% timing.Article: 119490
> > I think you misunderstood my question. I am not asking about a > synchronous vs. asynchronous reset and about reset release. I'm asking > about filtering potential noise that may be present on the reset_n > line on the board that goes between the voltage supervisor and the > FPGA. > If you have some reason for suspecting that the reset_n signal is noisy then you should address that with board level changes to get rid of the noise source. If your FPGA and board design happens to have a single clock source then synchronizing the incoming reset signal to that clock before distributing it anywhere would make the design somewhat more immune to ground bounce of the chip relative to the plane since the reset signal would only be sampled at the clock edge and the I/O switching which causes the bounce will occur after that edge. If you don't happen to have this special case though then you'll need to deal with the noise source directly as I mentioned. I'm suspecting though that the reason for the question is because you think 'reset_n' is such an important signal that some form of noise filtering should be done. That reasoning though is flawed. I'm guessing that there are probably very few inputs to your FPGA design that could tolerate noise to the extent that the logic level gets misinterpreted. Reset just happens to be one of your inputs, what about noise on any of the rest? KJArticle: 119491
On 21 Mai, 13:18, dalai lamah <antonio12...@hotmail.com> wrote: > Un bel giorno J.Ram digit=F2: > > > but timing are not met for 90Mhz. > > but design is working on board for 90Mhz clcock. > > As far as I know, the timing extimations in ISE are made assuming always > the worst case scenario (worst temperatures, worst limit of each specified > parameter, etc). They represent a "lower performance limit", True. Another aspect is that static timing analysis is pessimistic. The slowest path reported might be a path that is never switching in the design scenario at hand or even can't switch under any circumstances (false path). Kolja SulimmaArticle: 119492
Hello everybody,
I was trying NGDbuild for a DDR memory controller
implementation. I am getting the following error:
ERROR:NgdBuild:924 - bidirect pad net 'cntrl0_ddr1_dq(0)' is driving
non-buffer
primitives:
pin I0 on block _n00001 with type LUT4
Does anybody encountered this before? Any suggestions will be helpful.
Thanks,
Koustav
Article: 119493Hi, Can I drive a LCVMOS25 (input) and a LVTTL (input/output) in the same bank even if there is VCCIO problems ? Thanks!Article: 119494
Use a good oscilloscope to monitor the FPGA clock input. If the rise/fall time is very fast 1 to 2 ns, then you should worry about reflections, and you need termination. If the rise/fall time is slow (tens of ns) then termination is not needed, but the signal is sensitive to noise. In either case, the FPGA interprets the falling clock edge as multiple edges, one of them a rising edge. Peter Alfke On May 21, 4:35 am, Venu <get2v...@gmail.com> wrote: > Thanks for the input Peter. I have started looking into the pointers > that you have provided. > > Just to make this discussion complete, I would like to record one > further observation that I made. > > The 2 MHz clock is driving the FPGA ( as I had previously mentioned ) > as well as a codec on the board. When the codec power supply is > switched off , then the FPGA is generating pulses at pulses at 500 ns > width ( 1 clock period of the 2MHz clock) . But as soon as the codec > is turned on , the FPGA pulses are now of 250 ns width. In both the > cases though , the external clock frequency remains 2.048 MHz. > > Uptil now my ucf setting for the clock pin input was as follows > NET TDM_CLK_pin LOC = "B16"; > NET TDM_CLK_pin IOSTANDARD = LVCMOS25; > > I will try to use any of the IOB settings to terminate the clock > properly. If I can solve this problem, I will report it in this > discussion. > > Thanks once again > Venu > > Peter Alfke wrote: > > Venu, > > I am sure that your problem is caused by poor signal integrity at the > > clock input to the FPGA. There may be overshoot, undershoot and > > ringing, which causes the FPGA to interpret the falling clock edge as > > another rising clock edge. > > Try to clean up the clock signal, terminate it properly. > > 2 MHz is a very low clock frequency, and it might have a slow rise/ > > fall time, which might be another source of double-triggering caused > > by noise during the transition. > > Peter Alfke, from home. > > > On May 19, 2:35 am, Venu <get2v...@gmail.com> wrote: > > > Hi People, > > > > I am attempting to interface the Xilinx Virtex - II Pro FPGA with a > > > quad channel codec. > > > > I am using XC2VP30-FF896 FPGA on the Xilinx University Program > > > Development Board.I had applied a 2.048MHz TDM clock to the FPGA pin > > > B16, which is the GCLK6S ( Global Clock Input). > > > > My problem is that by the time this clock reaches my IP on the OPB > > > Bus , its frequency doubles!! I have confirmed this by checking > > > pulses generated on the basis of this clock, on a Digital > > > Oscilloscope. > > > > I have confirmed that I have not instantiated a DCM in the external > > > clock path . The resource utilisation shows that the system uses only > > > 1 DCM , which is attached to the sys_clk_s. > > > > For now , to make my system work , i have divided the clock frequency > > > inside my IP and then applied it to the individual block. But the > > > confusion of why this exactly happened still remains. > > > > Thanks > > > VenuArticle: 119495
Nico Coesel schrieb: > Antti <Antti.Lukats@googlemail.com> wrote: > > >Hi > > > >http://code.google.com/p/fpga-retro/downloads/list > > > >there is the distribution archive for the one chip MSX project > >would be fun to convert it for some xilinx board, :) > > > >I have been hunting for those VHDL code for ages, all links ended > >dead somewhere, but with heavy searching the archive was found too. > > > >Antti > > Cool! Is it the MSX-I or MSX-II? I believe I have the MSX-II video > chip in VHDL somewhere... Never bothered to do something with it > though. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl hum,, good question, need look sources to understand i guess.. I just uploaded the "XST fixed" VHDL sources also, they are good at least for resource estimate runs. 100% of logic and BRAM of XC3S1000 AnttiArticle: 119496
Hello I get the same problem working with Spartan 3 and Virtex II Pro, it started when I was trying the ISE 9.1i Quick Start Tutorial (am new to ISE in general), when it comes to pin assigning the pins, PACE gives me this message: "PACE was unable to parse the HDL source file 'C:\...\counter.vhd' " and after that PACE shows this (whatever you call it): Loading device for application Rf_Device from file '3s200.nph' in environmentC:\Xilinx91i. ERROR:HDLParsers:3562 - pepExtractor.prj line 1 Expecting 'vhdl' or 'verilog' keyword, found 'work'. I searched and search, and the only result was this topic ... so I sent an Email to mludwig hoping that he knows by now an answer for this, but he didnt answer me :-( So I am trying to refresh the topic ... Thats all for the moment, thank you! note: sorry for my bad English.Article: 119497
"LilacSkin" <lpaulo07@iseb.fr> wrote in message news:1179758942.207465.14080@36g2000prm.googlegroups.com... > Hi, > > Can I drive a LCVMOS25 (input) and a LVTTL (input/output) in the same > bank even if there is VCCIO problems ? > > Thanks! Since the LVTTL requires 3.3V, the software won't let you do that. You can, perhaps, receive signals that aren't VCCIO compliant as outputs. Your data sheet will show what signals can be received at which VCCIO bank standard.Article: 119498
KJ, > Another example of such a difference between when a particular type is good > to use or not would be between the use of type 'unsigned' or type 'natural' > when creating a counter (or adder). In the hands of the more skilled > designer, type 'natural' is usually preferred; in the hands of the less > skilled the use of type 'natural' can cause problems because signals of type > natural will always magically initialize to 0 in simulation. Do you find that you are getting good usage of carry out in place of zero detection with natural? For example, with unsigned, I can explicitly code the carry out by adding one bit to my decrement resource (variable Count17) as shown below. As a result, the zero detect is implemented as a single carry/borrow cell (one LUT) for any size of counter. If you do a test, make sure to use at least 16 bits so you can notice the difference. signal EndDetect : std_logic ; signal Count16Reg : unsigned(15 downto 0) ; ... process (...) variable count17 : unsigned(16 downto 0) ; begin ... Count17 := Count17 - 1 ; EndDetect <= Count17(16) ; -- carry bit. Count16Reg <= Count17 (15 downto 0) ; ... Now if the current generation of synthesis tools can always extract this information from the following, then there is no point in working to create the result with unsigned. signal EndDetect : std_logic ; signal CountReg : natural range 0 to 2**16 - 1 ; ... CountReg <= CountReg - 1 ; ... EndDetect <= '1' when CountReg = 0 else '0' ; WRT initialzation, you will always find that in gate sims, however, it is not a nice time to find it if a rookie forgets to reset many registers. Cheers, JimArticle: 119499
I would like to know if an FPGA needs CPU for processing a packet/ frame that it receives. For example an FPGA is capable of processing a frame based on its destination Address (similar to layer 2 ethernet device). Does the FPGA takes help of CPU in actually moving the frame from one port to another port? Or does it do on its own. My understanding of an FPGA is that during the start up time we need to register the FPGA with the processor. We also register the actions that we perform, interrupts. We configure the FPGA to do specific job during the FPGA initialization. After that FPGA does not use CPU for any of the internal work it has to do. It can talk to the CPU in case of exceptions, so that CPU can look at the packet and do more application level processing. Thanks.
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