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 10 Mai, 10:46, "Marco T." <marcotos...@gmail.com> wrote: > Hallo, > do you know a way to perform gain and offset correction of the adc > output in vhdl? > > Many Thanks > Marco T. yes we know the way, we always do. AnttiArticle: 119051
Schematics for Craignell3 (40 pin dil) are now on the engineering website here http://www.enterpoint.co.uk/component_replacements/craignell.html. John Adair Enterpoint Ltd. On 10 May, 07:15, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > On 2007-05-10, John Adair <g...@enterpoint.co.uk> wrote: > > > We have just posted the schematics to this product and given some more > > details on I/O counts on our engineering website. Details are here > >http://www.enterpoint.co.uk/moelbryn/darnaw1.html. > > Do you by any chance have the same kind of information available for > the Craignell modules? (I'd like to know what pins are used for > ground and 5V to see if I would be able to use this kind module to > repair/improve some old computers I have in storage.) > > /AndreasArticle: 119052
We have now posted schematics for the 40 pin variant of Craignell on our engineering website for those interested in more details. It's here http://www.enterpoint.co.uk/component_replacements/craignell.html. John Adair Enterpoint Ld.Article: 119053
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1178787120.297639.75380@q75g2000hsh.googlegroups.com... > On 10 Mai, 10:46, "Marco T." <marcotos...@gmail.com> wrote: >> Hallo, >> do you know a way to perform gain and offset correction of the adc >> output in vhdl? >> >> Many Thanks >> Marco T. > > yes we know the way, we always do. > > Antti > I know TWO ways! BWAAHAHAHAHA! HTH, Syms. :-)Article: 119054
On 10 Mai, 11:30, "Symon" <symon_bre...@hotmail.com> wrote: > "Antti" <Antti.Luk...@xilant.com> wrote in message > > news:1178787120.297639.75380@q75g2000hsh.googlegroups.com...> On 10 Mai, 10:46, "Marco T." <marcotos...@gmail.com> wrote: > >> Hallo, > >> do you know a way to perform gain and offset correction of the adc > >> output in vhdl? > > >> Many Thanks > >> Marco T. > > > yes we know the way, we always do. > > > Antti > > I know TWO ways! BWAAHAHAHAHA! > > HTH, Syms. :-) I see, you mean: way 1: the way you are on way 2: where all the others go... I think we all chose way #1 always :) AnttiArticle: 119055
On 10 May 2007 01:45:16 -0700, John Adair <g1@enterpoint.co.uk> wrote: >On 10 May, 07:15, Andreas Ehliar <ehl...@lysator.liu.se> wrote: >> On 2007-05-10, John Adair <g...@enterpoint.co.uk> wrote: >> >> > We have just posted the schematics to this product and given some more >> > details on I/O counts on our engineering website. Details are here >> >http://www.enterpoint.co.uk/moelbryn/darnaw1.html. >> >> Do you by any chance have the same kind of information available for >> the Craignell modules? (I'd like to know what pins are used for >> ground and 5V to see if I would be able to use this kind module to >> repair/improve some old computers I have in storage.) >> >> /Andreas > >Andreas > >It is not on the web web yet. I will see if I can hurry it up. The >power pins on Craignell are in the traditional DIL positions i.e. top >right for 5V and bottom left for gnd as you look down on top. > >One word of warning - we had a big uptake of the Craignell modules and >stocks have gone. Lead time maybe currently 4-6 weeks. We trying to >improve that but our assembly line is very busy. Basically we under >estimated demand but once this initial shortage is sorted I expect >these modules to be a stock item. > >John Adair >Enterpoint Ltd. > > I've been keeping an eye on your products for a while as I think there is a big market for this type of module for low-volume applications & I have a few apps of my own in mind - one of the great strengths of FPGAs is they are ideal for custom and low-volume apps, but this is frustrated by the packaging and fiddly extras like config and power. Both the Craignell and Darnaw look very interesting, but I think there may be room for something in the middle pin-wise - maybe a similar general shape to the 40DIP , but with 2 rows of pins on each side, the inner rows corresponding to the 40 pin footprint. This would provide a lot more IO (and grounds if necessary) whilst still making it viable to route on a 2-layer (1 signal + 1 mostly groundplane) PCB, or a vero microboard style prototyping board. And you could put it in a 40 pin socket if you didn't need the extra IOs. A regards IO, I'm not sure how important 5V is as pretty much everything is 3.3v nowadays - I'd personally have much preferred to see a fast SRAM instead of the bus translators on Craignell.Article: 119056
On 10 Mag, 11:38, Antti <Antti.Luk...@xilant.com> wrote: > On 10 Mai, 11:30, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > > > "Antti" <Antti.Luk...@xilant.com> wrote in message > > >news:1178787120.297639.75380@q75g2000hsh.googlegroups.com...> On 10 Mai, 10:46, "Marco T." <marcotos...@gmail.com> wrote: > > >> Hallo, > > >> do you know a way to perform gain and offset correction of the adc > > >> output in vhdl? > > > >> Many Thanks > > >> Marco T. > > > > yes we know the way, we always do. > > > > Antti > > > I know TWO ways! BWAAHAHAHAHA! > > > HTH, Syms. :-) > > I see, you mean: > > way 1: the way you are on > way 2: where all the others go... > > I think we all chose way #1 always :) > > Antti- Nascondi testo tra virgolette - > > - Mostra testo tra virgolette - Ahah...Article: 119057
Hi http://www.altera.com/b/arriagx.html?WT.mc_id=ag_en_mx_nk_tx_1_192 After Lattice ECP2M now also Altera has announced low cost FPGA family with high speed Serdes ! AnttiArticle: 119058
Dear All, I'm sure this question was already been posted (and answered) in this list, but I could not find a suitable answer for my little knowledge of this matters, so, with my apologies, i'm posting it again. I'm developing a microblaze system based on the Spartan-3 starter kit board. I need to access the on-board SRAM from my C code. I have hooked the SRAM to the OPB bus using BSB. The automatically generated memory_test application works just fine. I just need the memory to hold data during program execution, e.g, int's, I d'ont have any sort of timing requirements. My question is: how i'm I suppose to read and write to/from the SRAM? Just use the XIo_Out/In(32, 16, 8) library functions or is their a more efficient way of accessing the memory? I'm particulary confused by the functions on the XEmc library, that are related to the SRAM, but I really d'ont know what they do. Tank you all, Jos=E9 MarianoArticle: 119059
On 10 Mai, 14:25, jmariano <jmarian...@gmail.com> wrote: > Dear All, > > I'm sure this question was already been posted (and answered) in this > list, but I could > not find a suitable answer for my little knowledge of this matters, > so, with my > apologies, i'm posting it again. > > I'm developing a microblaze system based on the Spartan-3 starter kit > board. I need to > access the on-board SRAM from my C code. I have hooked the SRAM to the > OPB bus using BSB. > The automatically generated memory_test application works just fine. > > I just need the memory to hold data during program execution, e.g, > int's, I d'ont have > any sort of timing requirements. > > My question is: how i'm I suppose to read and write to/from the SRAM? > Just use the > XIo_Out/In(32, 16, 8) library functions or is their a more efficient > way of accessing the > memory? I'm particulary confused by the functions on the XEmc library, > that are related > to the SRAM, but I really d'ont know what they do. > > Tank you all, > > Jos=E9 Mariano a small hint: just look the way the Xio_out is actually done in the xilinx library source. there you see how todo it. its just standard C pointer access to raw memory AnttiArticle: 119060
Hey All, Thanx for the suggestions. I also got a response from ModelSIM on this one.. apparently simulators do not just "unroll" the loop the same way synthesizers do (although, it sounds like not all synthesizers). The loop generate wrapped around the process is indeed the right answer. Thanx -Paul On May 9, 3:04 pm, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote: > Paul schrieb: > > > Can't figure it out... Why cant this compile: > > > S_chan0_clk : process (reset_delayed, ch_clk_div_int) > > begin > > for k in 0 to 15 loop > > test_case := ch_clk_div_int(k); > > if reset_delayed = '1' then > > reset_chan_Q(k) <= '1'; > > reset_chan_QQ(k) <= '1'; > > elsif ch_clk_div_int(k) = '1' AND ch_clk_div_int(k)'EVENT then > > reset_chan_Q(k) <= '0'; > > reset_chan_QQ(k) <= reset_chan_Q(k); > > end if; > > end process; > > move that for-loop outside of this process and change it to a > for-generate. (And don't forget the "end generate;" - you have forgotten > the "end loop;") > > my_gen_label : for k in 0 to 15 generate > -- your process here > end generate; > > Note that not all synthesis tools accept the a vector element inside a > rising_edge() expression. E.g. Synopsys Design Analyzer does not accept > "rising_edge(ch_clk_div_int(k))". This is pretty annoying. > > RalfArticle: 119061
Mike The main target for Craignell is the obsolete and enhanced component markets and that is why it has 5V tolerance and drive levels. It happens to useful for some hobby, student and lash ups as a bit of a by-product. We are considering a mid-range module between the Craignells and Darnaws but no timescales or definates yet as we want to gauge the popularity of Craignell and Darnaw. The Darnaw1 can be run with just outer and inner pin rows only and still has 110 I/O to use in this configuration as a stop gap solution. I would think a 2 layer pcb would support this and even a stripboard mount is feasible (do I hear you all shuddering). We have made the decoupling on Darnaw1 reasonable to cope with relatively electrical poor hosts but how bad and still work will really depend on your application. I'll say again that anyone identifies a real market for a product we don't already do it is worth talking to us offline. Assuming we have the manpower resource spare (which has not been much lately - now improving with extra teams) it can be a surprise at how quickly products can go from concept to being in customer hands. There is a product in our main development board range(not modules) that went from a customer request to being in their hands, tested, and working in 18 calendar days. We have another product at about 25 days development. Those remain as products which are essentially are still first issue products. I won't say which as it might be a competition answer yet but you are welcome to make your own guesses or a google search. John Adair Enterpoint Ltd. On 10 May, 11:01, Mike Harrison <m...@whitewing.co.uk> wrote: > On 10 May 2007 01:45:16 -0700, John Adair <g...@enterpoint.co.uk> wrote: > > > > > > >On 10 May, 07:15, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > >> On 2007-05-10, John Adair <g...@enterpoint.co.uk> wrote: > > >> > We have just posted the schematics to this product and given some more > >> > details on I/O counts on our engineering website. Details are here > >> >http://www.enterpoint.co.uk/moelbryn/darnaw1.html. > > >> Do you by any chance have the same kind of information available for > >> the Craignell modules? (I'd like to know what pins are used for > >> ground and 5V to see if I would be able to use this kind module to > >> repair/improve some old computers I have in storage.) > > >> /Andreas > > >Andreas > > >It is not on the web web yet. I will see if I can hurry it up. The > >power pins on Craignell are in the traditional DIL positions i.e. top > >right for 5V and bottom left for gnd as you look down on top. > > >One word of warning - we had a big uptake of the Craignell modules and > >stocks have gone. Lead time maybe currently 4-6 weeks. We trying to > >improve that but our assembly line is very busy. Basically we under > >estimated demand but once this initial shortage is sorted I expect > >these modules to be a stock item. > > >John Adair > >Enterpoint Ltd. > > I've been keeping an eye on your products for a while as I think there is a big market for this type > of module for low-volume applications & I have a few apps of my own in mind - one of the great > strengths of FPGAs is they are ideal for custom and low-volume apps, but this is frustrated by the > packaging and fiddly extras like config and power. > > Both the Craignell and Darnaw look very interesting, but I think there may be room for something in > the middle pin-wise - maybe a similar general shape to the 40DIP , but with 2 rows of pins on each > side, the inner rows corresponding to the 40 pin footprint. This would provide a lot more IO (and > grounds if necessary) whilst still making it viable to route on a 2-layer (1 signal + 1 mostly > groundplane) PCB, or a vero microboard style prototyping board. And you could put it in a 40 pin > socket if you didn't need the extra IOs. > > A regards IO, I'm not sure how important 5V is as pretty much everything is 3.3v nowadays - I'd > personally have much preferred to see a fast SRAM instead of the bus translators on Craignell.- Hide quoted text - > > - Show quoted text -Article: 119062
When i add these 2 constraint to my UCF file: CONFIG POST_CRC = "ENABLE"; CONFIG POST_CRC_SIGNAL = "FRAME_ECC_ONLY"; I get these error messages while doing the timing driven packing phase in the map command. ERROR:Place:911 - CONFIG POST_CRC = ENABLE is not a valid constraint. ERROR:Place:911 - CONFIG POST_CRC_SIGNAL = FRAME_ECC_ONLY is not a valid constraint. The ngdbuild phase had 0 warnings and errors so i have no indications what could be the problem. Thankful for any suggestions. /PeterArticle: 119063
On May 10, 12:51 am, Peter Alfke <a...@sbcglobal.net> wrote: > Use Frequency Synthesis mode driving the Fx output. > Then you do not have the min input frequency limitation, and you can > multiply and divide (simultaneously!) the input frequency by any > integer up to 32. So you just multiply by 8 and divide by 1 to get 240 > MHz. > Peter Alfke, Xilinx Applications, from home > > On May 9, 9:43 pm, fastgreen2...@yahoo.com wrote: > > > I'm restricted to 30Mhz LVDS clock input. From this, I need to > > generate 240Mhz to be used internally. Restriction comes an ASIC that > > I'm interfacing to. What options do I have here? > > > Based on what I see in ds302 by Xilinx, I haven't found a clean (or, > > any) solution. Minimum clock speed I need is 32Mhz for DCM. If the > > min speed weren't an issue, I could cascade two DCMs - 4x and 2x - to > > get 8x. (I know, cascading is not ideal due to jitter). > > > Am I stuck? The 30Mhz clock is actually for data coming in at 240Mhz > > rate. > > > Is there any way out of this? Hello Peter, thanks... could you tell me where it is documented? I remember that vaguely from the Virtex(2?) days, but can't remember the details. Also, but when I tried to verify that using core generator (I normally instantiate DCM manually instead of using coregen, btw), it says "The specified input clock frequency restricts your output frequency to LOW frequency range. Either change your input clock frequency or your M/D value to correct this." Is it a tool issue? Thanks again.Article: 119064
Hello all, since one week no progress - many, many problems... Using Webpack at the moment, as mentioned 9.1.03i. I have a top level schematic with an Softcore + one RAM and one ROM, both generated with Block Memory Generator v2.4, so two *.XCO-files. 1. When I change the *.COE-file of my ROM, it last ~5 minutes until the core is updated, sometimes XST hangs and I must reboot. 2. Usually I get the following error message when starting a behavioral simulation: WARNING:Simulator:29 - No entity is bound... That means the RAM and ROM are not found. I'm not using testbench files at the moment. There are many other issues and crazy warnings, can't mention all here. Summarized, a cleanup of the generated files seems to help, at least sometimes. Now I want to force my address-bus addra[12:0] of that ROM: isim force add /mc8051UW_Top1a/ROM/addra 0 which crashes the simulator. So how can I assign a bus value with the "isim force add"-command? Can I start Tcl-Scripts in the ISE Simulator Shell, like with the "do"- command in ModelSim? I tried to use Memories generated with the Single Port Block Memory v6.2-Generator, seems to work better. What are your experiences concerning the stability of Xilinx ISE 9.1.03i? Thanks for any help UdoArticle: 119065
What part are you targetting? Ben <peter> wrote in message news:eea6b0c.-1@webx.sUN8CHnE... > When i add these 2 constraint to my UCF file: CONFIG POST_CRC = "ENABLE"; > CONFIG POST_CRC_SIGNAL = "FRAME_ECC_ONLY"; > > I get these error messages while doing the timing driven packing phase in > the map command. > > ERROR:Place:911 - CONFIG POST_CRC = ENABLE is not a valid constraint. > ERROR:Place:911 - CONFIG POST_CRC_SIGNAL = FRAME_ECC_ONLY is not a valid > constraint. > > The ngdbuild phase had 0 warnings and errors so i have no indications what > could be the problem. > > Thankful for any suggestions. > > /PeterArticle: 119066
On May 9, 7:16 pm, Jeff Cunningham <j...@sover.net> wrote: > Guru wrote: > > > Ave Paul! There is a lack of fast and free TCP/IP stacks which work > > with TEMAC. It would be nice to port your stack to GSRD design > > (www.xilinx.com/gsrd) to get a maximum speed and royalty free > > reference design. I got this design working on Avnet Virtex-4FX12 > > MiniModule, which is a low cost high performance OEM module. > > Unfortunatelly there are no good reference designs which can exploit > > this performance. If I were a better SW engineer I could help you on > > development from which both would benefit. > > > Guru > > Hi Guru, > > I am the hardware engineer who is working with Paul. I'd love to hear > any comments you might have on our approach. > > Our application specific IP that must also fit in the FPGA is a PLB > master DMA device that uses about 50% of the BRAM and 25% of the fabric > in the FX12. We originally were going to use the FX12 Minimodule, but > switched to the ML403 to get 2x the DDR bandwidth. We can get by with > 400 Mb/s performance for now, but would like to get 800 Mb. > > It seemed like all the GSRD examples almost filled a FX12, particularly > with BRAM usage, so we used the EDK supplied PLB TEMAC core and the PLB > DDR controller for now. > > Since our app only needs high speed in the receive direction, it seemed > like it should be possible to remove half the GSRD logic (i.e. the > transmit part) and then everything would fit. As someone who has worked > with the GSRD, do you have a feel for how hard this would be? Or would > you guess the full GSRD (both directions) could fit with our IP somehow? > The critical resource seems to be BRAM and it always seemed like the > xilinx IP really used more BRAM that it should. > > thanks, > Jeff Jeff, My GSRD design uses about 70% of FX12 logic resources and about 60% of BRAMs. BRAM usage is easy to control since you can set FIFO size from 1BRAM for a MPMC2 port. The best of MPMC2 is an NPI port which simplifies the user peripherals with DMA - what I use for image acquisition. I also tested TEMAC transfer rates to the PC: 730Mbit 1.5k MTU and 850Mbit for 7k MTU. If you need any additional resources do not hesiste to contact me. GuruArticle: 119067
Hello, im targeting xc5vlx30-2-ff676. /PeterArticle: 119068
Ok, sounds strange that it would give you this error... http://toolbox.xilinx.com/docsan/xilinx82/books/docs/cgd/cgd.pdf Is pretty detailed... That and the UG191 explains exactly what you said. Could it be something really simple... Have you tried without the speech marks? Ben <peter> wrote in message news:eea6b0c.1@webx.sUN8CHnE... > Hello, > > im targeting xc5vlx30-2-ff676. > > /PeterArticle: 119069
Click on the Virtex-4 User Guide http://direct.xilinx.com/bvdocs/userguides/ug070.pdf Then read page 55 (in the center of the page) and pages 63, 74, and 75. In Frequency Synthesis mode, the Fmin limit (~30 MHz) applies to the output frequency, not the input frequency. You should have no problem. Peter Alfke On May 10, 6:13 am, fastgreen2...@yahoo.com wrote: > On May 10, 12:51 am, Peter Alfke <a...@sbcglobal.net> wrote: > > > > > Use Frequency Synthesis mode driving the Fx output. > > Then you do not have the min input frequency limitation, and you can > > multiply and divide (simultaneously!) the input frequency by any > > integer up to 32. So you just multiply by 8 and divide by 1 to get 240 > > MHz. > > Peter Alfke, Xilinx Applications, from home > > > On May 9, 9:43 pm, fastgreen2...@yahoo.com wrote: > > > > I'm restricted to 30Mhz LVDS clock input. From this, I need to > > > generate 240Mhz to be used internally. Restriction comes an ASIC that > > > I'm interfacing to. What options do I have here? > > > > Based on what I see in ds302 by Xilinx, I haven't found a clean (or, > > > any) solution. Minimum clock speed I need is 32Mhz for DCM. If the > > > min speed weren't an issue, I could cascade two DCMs - 4x and 2x - to > > > get 8x. (I know, cascading is not ideal due to jitter). > > > > Am I stuck? The 30Mhz clock is actually for data coming in at 240Mhz > > > rate. > > > > Is there any way out of this? > > Hello Peter, thanks... could you tell me where it is documented? I > remember that vaguely from > the Virtex(2?) days, but can't remember the details. Also, but when I > tried to verify that using > core generator (I normally instantiate DCM manually instead of using > coregen, btw), it says > > "The specified input clock frequency restricts your output frequency > to LOW frequency range. > Either change your input clock frequency or your M/D value to correct > this." > > Is it a tool issue? > > Thanks again.Article: 119070
After answering you from memory, I studied the data sheet more carefully: http://direct.xilinx.com/bvdocs/publications/ds302.pdf You need to be in High Frequency Mode, where you can generate Fx output frequencies between 210 and 300 MHz, as shown on page 35 at the top. One inch further down, there is a Fmin spec of 50 MHz which you can ignore. It was put in there as a precaution against excessive jitter on the input. Hopefully, your clock does not have excessive jitter. Peter Alfke On May 10, 8:31 am, Peter Alfke <p...@xilinx.com> wrote: > Click on the Virtex-4 User Guidehttp://direct.xilinx.com/bvdocs/userguides/ug070.pdf > Then read page 55 (in the center of the page) and pages 63, 74, and > 75. > In Frequency Synthesis mode, the Fmin limit (~30 MHz) applies to the > output frequency, not the input frequency. You should have no problem. > Peter Alfke > > On May 10, 6:13 am, fastgreen2...@yahoo.com wrote: > > > On May 10, 12:51 am, Peter Alfke <a...@sbcglobal.net> wrote: > > > > Use Frequency Synthesis mode driving the Fx output. > > > Then you do not have the min input frequency limitation, and you can > > > multiply and divide (simultaneously!) the input frequency by any > > > integer up to 32. So you just multiply by 8 and divide by 1 to get 240 > > > MHz. > > > Peter Alfke, Xilinx Applications, from home > > > > On May 9, 9:43 pm, fastgreen2...@yahoo.com wrote: > > > > > I'm restricted to 30Mhz LVDS clock input. From this, I need to > > > > generate 240Mhz to be used internally. Restriction comes an ASIC that > > > > I'm interfacing to. What options do I have here? > > > > > Based on what I see in ds302 by Xilinx, I haven't found a clean (or, > > > > any) solution. Minimum clock speed I need is 32Mhz for DCM. If the > > > > min speed weren't an issue, I could cascade two DCMs - 4x and 2x - to > > > > get 8x. (I know, cascading is not ideal due to jitter). > > > > > Am I stuck? The 30Mhz clock is actually for data coming in at 240Mhz > > > > rate. > > > > > Is there any way out of this? > > > Hello Peter, thanks... could you tell me where it is documented? I > > remember that vaguely from > > the Virtex(2?) days, but can't remember the details. Also, but when I > > tried to verify that using > > core generator (I normally instantiate DCM manually instead of using > > coregen, btw), it says > > > "The specified input clock frequency restricts your output frequency > > to LOW frequency range. > > Either change your input clock frequency or your M/D value to correct > > this." > > > Is it a tool issue? > > > Thanks again.Article: 119071
Eli, I believe that iMAPCT Help is the correct place to have this information. However, I feel that there could be more detail in the Platform Flash UG. It only states that revisioning is supported in serial and parallel modes. I think that there is room to be more specific about where and how the configuration modes are controlled (i.e. maybe a link to the Help guide). As it turns out (and I did verify this with engineering) there is only a single register to control the download mode in the PROM. It is a global setting and all revisions are either serial or parallel. The engineering group is open to suggestions and if a good case can be presented on why each revision should have individual control over its configuration mode, we would be very interested in hearing them. -David <eli.billauer@gmail.com> wrote in message news:1178699860.052524.320740@e65g2000hsc.googlegroups.com... > Thank you for the answers. Indeed, I found the following sentence in > the help page for configuration options: > > "Parallel Mode > > Sets the parallel mode bit in the XC18V00 device. The PROM uses the DO- > D7 pins for SelectMap programming of the target FPGA." > > That's good enough for going ahead with the board. But I still wonder > if this is written somewhere in the official docs. After all, this is > a major issue, and still I couldn't find a word about this in the data > sheet (ds123.pdf) nor the user guide (ug161.pdf). Is the info out > there in a place I don't look? > > Thanks again, > Eli > > >Article: 119072
Peter - thanks again. So, I can use 30mhz CLKIN to create CLKFX @240mhz (M=8,D=1)... but can I use CLKFB to remove the insertion delay here? All documents I looked at talk about CLKIN out of the range _and_ using only FX outputs (with no CLKFB hooked up). I can see why that's the case. If that's the case, how do I receive the 240Mhz data that's synchronous to the 30Mhz input clock - the delay from the pad thru ibufg, dcm, bufg is not quantified, I don't believe. I wouldn't know how to align the clock to the data. (In the lab, I can, but not over temp, volt, etc...) I mentioned receiving the data in the original post, maybe it got missed.Article: 119073
On May 9, 10:58 pm, yao.s...@gmail.com wrote: > Hi, everyone > > I've been stuck on this problem for a couple of days, and still > couldnt figure out how this happen. > I have an XPS/ISE combined project. The part of ISE project is a > hardware accelerator which is connected to powerpc system generated by > XPS via dsocm. After I merged both projects in ISE and tried to > implement it to fpga, the weird thing happened!!! My logic was almost > removed by 25% after XIlinx Map. Firstly, I synthesized the whole > project using XST. The synthesis report looks pretty right, about 30% > of slice are consumed. And then I moved on to do translation, the > report looks more or less the same. But after mapping, the logic > utilization reduces to only 5%!!! Almost everything inside the > hardware accelerator are removed. At the beginning, I assume there > must be something wrong with the connection between the ppc_subsystem > and the hardware accelerator. I triple checked the top level vhdl code > but couldnt find anything wrong. I tried many many times re-mapping, I > still got the 5% logic left. The hardware accelerator can function > correcly and was verified by modelsim and can be correctly PAR, the > logic utilization of which is around 30%. The ppc_subsystem can be > correctly PAR as well, and consumes 4% of total fpga fabric. Both > things can be synthesized but once after MAP, the total logic has been > removed by 25%. I really cannot understand why the logic be removed > even everything is in good connection. > > Hardware Accelerator Only > --------------------------------------------------------------------------------------------------- > Device Utilization Summary > Logic Utilization Used Available Utilization Note(s) > Number of Slice Flip Flops 8,485 27,392 30% > Number of 4 input LUTs 5,421 27,392 19% > Logic Distribution > Number of occupied Slices 4,859 13,696 35% > Number of Slices containing only related logic 4,859 4,859 100% > Number of Slices containing unrelated logic 0 4,859 0% > Total Number 4 input LUTs 6,387 27,392 23% > Number used as logic 5,421 > Number used as a route-thru 109 > Number used for Dual Port RAMs 228 > Number used as Shift registers 629 > Number of bonded IOBs 147 556 26% > IOB Flip Flops 1 > Number of PPC405s 0 2 0% > Number of Block RAMs 29 136 21% > Number of MULT18X18s 48 136 35% > Number of GCLKs 2 16 12% > Number of GTs 0 8 0% > Number of GT10s 0 0 0% > Number of RPM macros 20 > Total equivalent gate count for design 2,281,651 > Additional JTAG gate count for IOBs 7,056 > ------------------------------------------------------------------------------------------------ > > Hardware Accelerator + PPC_subsystem > ------------------------------------------------------------------------------------------------ > Device Utilization Summary > Logic Utilization Used Available Utilization Note(s) > Number of Slice Flip Flops 1,370 27,392 5% > Number of 4 input LUTs 1,486 27,392 5% > Logic Distribution > Number of occupied Slices 1,437 13,696 10% > Number of Slices containing only related logic 1,437 1,437 100% > Number of Slices containing unrelated logic 0 1,437 0% > Total Number 4 input LUTs 1,796 27,392 6% > Number used as logic 1,486 > Number used as a route-thru 68 > Number used for Dual Port RAMs 188 > Number used as Shift registers 54 > Number of bonded IOBs 4 556 1% > IOB Flip Flops 2 > Number of PPC405s 2 2 100% > Number of JTAGPPCs 1 1 100% > Number of Block RAMs 48 136 35% > Number of GCLKs 2 16 12% > Number of DCMs 1 8 12% > Number of GTs 0 8 0% > Number of GT10s 0 0 0% > Total equivalent gate count for design 3,201,070 > Additional JTAG gate count for IOBs 192 > ----------------------------------------------------------------------------------------------------------------- > > Has anyone experienced this before? > > Thanks in advance, > > Yao Hello Yao, There are some known issues with trimming in designs with hierarchy. This is scheduled to be fixed in ISE 9.2i. You can easily determine whether your design has this problem by running MAP with the "- ignore_keep_hierarchy" to see if the problem goes away. Since you're using ISE 8.1i, you may be running into a problem with RAM feedback paths that was fixed in 8.2i. See Xilinx Answer 23284 for details. Xilinx Answer 23990 is a comprehensive descussion of MAP trimming issues. Regards, BretArticle: 119074
Guys I am trying to simulate the BSCAN_VIRTEX5 component. The Xilinx simulation guide, sim.pdf, says that you can instantiate a JTAG_SIM_VIRTEX5 in your testbench to control the BSCAN component. So far I have been unable to get either the ISE simulator or the Aldec simulator to resolve the JTAG_SIM_VIRTEX5 component. I get this message in the ISE simulator: "Undefined symbol 'JTAG_SIM_VIRTEX5". Can anyone tell me what library I need to include in my testbench to resolve the JTAG_SIM_VIRTEX5 component? For reference I include my testbench VHDL. Thanks Pete --------------------------------------------------------------------------- LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_arith.all; library UNISIM; use UNISIM.VComponents.all; use UNISIM.VPKG.all; ENTITY jtag_interface_tb_vhd IS END jtag_interface_tb_vhd; ARCHITECTURE behavior OF jtag_interface_tb_vhd IS signal tdo, tck, tdi, tms : std_logic; COMPONENT jtag_interface PORT( data_in : IN std_logic_vector(31 downto 0); clk_out : OUT std_logic; addr_out : OUT std_logic_vector(31 downto 0); data_out : OUT std_logic_vector(31 downto 0); we : OUT std_logic); END COMPONENT; SIGNAL data_in : std_logic_vector(31 downto 0) := (others=>'0'); SIGNAL clk_out : std_logic; SIGNAL addr_out : std_logic_vector(31 downto 0); SIGNAL data_out : std_logic_vector(31 downto 0); SIGNAL we : std_logic; constant tck_period : time := 1us; BEGIN JTAG_SIM_VIRTEX5_inst : JTAG_SIM_VIRTEX5 generic map (PART_NAME => "LX30") -- Specify target V5 device. Possible values are: "LX30", "LX50", "LX85", "LX110", "LX220", "LX330" port map ( TDO => TDO, -- JTAG data output (1-bit) TCK => TCK, -- Clock input (1-bit) TDI => TDI, -- JTAG data input (1-bit) TMS => TMS -- JTAG command input (1-bit) ); -- Instantiate the Unit Under Test (UUT) uut: jtag_interface PORT MAP( clk_out => clk_out, addr_out => addr_out, data_out => data_out, data_in => data_in, we => we); tck_proc:process begin tck <= '0'; wait for tck_period/2; tck <= '1'; wait for tck_period/2; end process; stim_proc: process begin -- force into reset state. tms <= '1'; tdi <= '0'; wait for tck_period*10; wait; end process; END;
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