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
Ulf Ochsenfahrt wrote:
> I've been having a really weird problem with a Xilinx Virtex-E XCV1000E
> development board from AVNET. I've got a VHDL design that I've been
> working on since october last year. When I upload the compiled design into
> the FPGA, everything works fine except after a couple of seconds (10s or
> so), the board resets itself and the FPGA is reprogrammed with the onboard
> design.
Get a schematic and see what can drive the reset line.
Reset should only occur at power-up or power overload.
Good luck.
-- Mike Treseler
Article: 80701
Johnson Lee wrote:
> I am writing a character controller using Altera MAXII device.
> This controller will monitor the input signals from lpt port. I make
> a simulation and download to real chip to verify function, but
> unfortunately it won't work as I designed.
It won't work as you *expected*.
> The simulation show that the state translate signals was initiated
> abnormal..
If the simulation doesn't work, there is a design error.
Debug it.
-- Mike Treseler
Article: 80702Hi everbody, The Stratix PCI kit is a 32/64-bits PCI board from Altera with 256 MB of DDR SDRAM (SO-DIMM). This kit includes a nice reference design that has a PCI to DDR bridge. We would like to use this design as a starting point for our own designs. Unfortunately this design only works with the old Quartus II v2.1 and the v1.2.1 SDRAM IP Megacore from Altera. Importing the older project in the newer Quartus 4.2 does not work. We tried creating a new project with the cores, pin settings, constraints etc. But the only thing that can be read from the DDR memory is garbage. Worse, it even gives this garbage when the SO-DIMM module isn't even inserted (it reads out: 9d66001b .... 9d22001b, while the working design gives something like ffff00 in that case (which is far more logical for disconnected hardware IMHO). We tested this with both the old and the new SDRAM Megacore. Could this be some project setting we overlooked? Byte lanes? Assignments? LogicLock settings? I tried asking Altera for help, they suggested downloading a newer PCI core because it included a newer reference design. Unfortunately that one doesn't use DDR but SDR instead. Then I asked if they could send me a reference design from one the newer kits (hoping to extract some useful information from it), and they said they can't (???). It probably has something to do with the datapath, because the system reads out garbage from the 'memory' even when the module isn't psysically present in the system. Though, I don't understand why... Anybody had any luck converting the (kit included) PCI 2 DDR reference design (Quartus II 2.1) to the new Quartus 4.2? Have a nice day!Article: 80703
Check the power rails are not dipping. If they do you could get a re-configure and subsequent reset. Also check there are no glitches on the PROG line. -- John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Ulf Ochsenfahrt" <ulfjack@gmx.de> wrote in message news:pan.2005.03.10.09.47.50.817957@gmx.de... > Hi! > > I've been having a really weird problem with a Xilinx Virtex-E XCV1000E > development board from AVNET. I've got a VHDL design that I've been > working on since october last year. When I upload the compiled design into > the FPGA, everything works fine except after a couple of seconds (10s or > so), the board resets itself and the FPGA is reprogrammed with the onboard > design. > > (There is a sample design in an onboard ROM chip. I download my design via > the JTAG interface.) > > When I take an old design (Tuesdays' in fact), everything runs fine and > stable. The only change is that I make two instances of a module instead > of one. The module is a self-written serial multiplier with RAM and ROM. > The only difference between the two instances is a different ROM > configuration (ROM data). The input lines (20-30 lines) are identical and > the output lines (three of them) are treated very similar. > > I have already consulted my University colleagues, but so far without > results. I already checked temperature, the clock/reset nets and I/O pin > assignment. Everything looks fine to me, but I'm certainly not an FPGA > wizard... > > Any ideas? Any recommended course of action? > > Thanks for your help! > > Cheers, > > -- UlfArticle: 80704
"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote in message news:1110455200.12605.0@echo.uk.clara.net... > Check the power rails are not dipping. If they do you could get a > re-configure and subsequent reset. I second that. I once had an embedded system that reset when using the FDD. Turned out my PSU wasn't quite beefy enough, hence when the motor turned on, Vcc dipped, casing a reset.Article: 80705
Hi everybody, we're two students looking for a low cost developer board for our diploma work. we intend to plug a camera to the pci board via 1394 and process the images throug the fpga and get the processed images from fpga via pci. The camera we will use, uses DCAM /IICD Now we have several problems: -we don't have a high budget, so it should be a low cost solution. -we have not jet found a board that fits our need, does anybody know something cheep that could fit our needs? -there would be several possibility to solve the connectivity problems: * best would be to find a board that fits our need, means have at least pci, fpga and 1394 on it? any suggestions ont htat? * if the above point can't be reached we could probably solder our 1394 interface ourself on a board. What would then be best for our purpose? We could probably use a TSB12LV32 chip from ti if we don't find a board with firewire. (http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html)? does anybody know this? would it then be possible to implement the dcam in the fpga? Thanks to everbodyArticle: 80706
Hi Andres, > What about Altera and Xilinx FPGAs ? Do they have more than one > global reset path ? In Stratix/Stratix II/Cyclone/Cyclone II/Max II I believe that you can route an async reset using any global clock or local routing. For example, Stratix II has 16 global clocks plus a bunch of quadrant-wide clocks. These clock networks can be used to route non-clock signals -- they are very good for distributing high-fanout signals. The clock networks can be driven directly by clock pins and by PLLs, or they can be fed from any other resource in the chip by routing a signal to an internal access port. The Quartus II software will automaticaly promote high-fanout and asynchronous signals onto the clock network (which are thus called "globals" in Quartus). Regards, Paul Leventis Altera Corp.Article: 80707
Austin, > Are you done changing the worst case numbers? No. If after further process monitoring and characterization we find that we can safely reduce our spec, we will be happy to do so. Just like our performance specs, which we have previously increased and will likely do again in the near future. What's your point? Are you suggesting that you are better off keeping your worst-case numbers to yourself, let users design using the typical numbers, and then unleash your worst-case numbers once you are 100% certain they won't change? I wouldn't want to be the guy with the chip on my board with a 2W thermal budget when I finally find out that V4 actually could burn 2.5X the static power I'd been told. Regards, Paul Leventis Altera Corp.Article: 80708
you can find it here: http://www.plsgoogleit.com/ "Nicolas Schwarzentrub" <schwn@hta-bi.bfh.ch> wrote in message news:d0pg8u$nco$1@news.hispeed.ch... > Hi everybody, > > we're two students looking for a low cost developer board for our diploma > work. we intend to plug a camera to the pci board via 1394 and process the > images throug the fpga and get the processed images from fpga via pci. The > camera we will use, uses DCAM /IICD > Now we have several problems: > -we don't have a high budget, so it should be a low cost solution. > > -we have not jet found a board that fits our need, does anybody know > something cheep that could fit our needs? > > -there would be several possibility to solve the connectivity problems: > > * best would be to find a board that fits our need, means have at least > pci, fpga and 1394 on it? any suggestions ont htat? > > * if the above point can't be reached we could probably solder our 1394 > interface ourself on a board. What would then be best for our purpose? We > could probably use a TSB12LV32 chip from ti if we don't find a board with > firewire. (http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html)? > does anybody know this? would it then be possible to implement the dcam in > the fpga? > > Thanks to everbodyArticle: 80709
Thanks for your replies, however, the problem is still unsolved: I looked through the schematics and it shows the board reset button with a pull-up resistor (I read that as low-active reset). This net is connected to an IC (the onboard ROM I guess) and to a certain pin on the FPGA. My thought then was that maybe the FPGA pulls down that pin for whatever reason. So I specified a pull-up in the constraints file. This helps. But not much. The board still resets itself, just after a slightly longer amount of time. Then, a colleague also said that it's most likely a problem with the power supply. So I got a fancy electronic power supply, where you can set the voltage to a certain level and it shows the current. The current tops at 1300 mA, which is more than the previous power supply could handle (it says 1200 mA max). The improved power supply helps. But, the board _still_ resets itself. Now here's something interesting: My old (working) design only draws 1000 mA. I am still investigating this. Thanks for your help. Cheers, -- UlfArticle: 80710
> Then, a colleague also said that it's most likely a problem withthe power supply. So I got a fancy electronic power supply, where you can set the voltage to a certain level and it shows the current. > > The current tops at 1300 mA, which is more than the previous power supply could handle (it says 1200 mA max). The improved power supply helps. But, the board _still_ resets itself. > > Now here's something interesting: My old (working) design only draws 1000 mA. > What about the powersupply on the board ? I'd guess you have an external power supply providing a single voltage and then on board several regulators to generate the voltages required by the FPGA ? Can theses handle the bigger current ? Maybe one of them is just heating, triggering thermal protection or ... SylvainArticle: 80711
What about the powersupply on the board ? I'd guess you have an external
power supply providing a single voltage and then on board several regulators
to generate the voltages required by the FPGA ? Can theses handle the
bigger current ? Maybe one of them is just heating, triggering thermal
protection or ...
Good point. The voltage regulators do get hot when I load my design. Fortunately, we got an office fan here, which we now installed above the board (looks pretty funny, if I had a camera, I'd take a picture). And now the board has been running fine for the last 5 minutes (wouldn't run longer than 30s before).
Seems odd though. The sample design (delivered with the board) is said to use ~600 mA and that is pretty small. Not to say tiny. Shouldn't the board have power regulators that can handle more than that? Or maybe they forgot to attach the heat sinks?
Thanks for pointing that out.
Cheers,
-- Ulf
Article: 80712Jason, All very good points. My point was simply that a power user trying to get the last 2 ps out of their design usually ends up using the features specific to that part, A or X. By doing so they often can use a lower speed grade part, or a smaller part, and save a lot of money. (No offense intended to anyone). Austin Jason Zheng wrote: > Austin Lesea wrote: > >> Mike, >> >> You know your business, that is for sure. And based on that, you make >> decisions. We have a number of customers who treat FPGAs as a commodity. >> >> Use no special features. Generic HDL only. >> >> Not my favorite model, but I know some folks use it. >> >> Austin > > I'm a big supporter of using generic HDL, because it makes your design > portable. It's portable not just in a sense that you can synthesize the > design on different platforms TODAY, but also that you can easily apply > it to TOMORROR's hardware. Portability is one of the big philosophies > behind the UNIX movement (and yes that is software, but the idea is the > same). Without it, UNIX wouldn't have survived past PDP-11. > > My point is, utilizing some special features may get you 20% more > performance today. But next year, some other vendor might come up with a > good platform that runs 50% faster than your current vendor's platform. > If you use generic HDL, very little, if any, efforts are needed to move > on to the better technology or platform. Whereas specialized HDL designs > will soon require too much effort to keep up with the new technology. > > Finally, the less technology-dependent your design is, the easier for > you to leverage the advancement of the synthesizers. Maybe the > synthesizers today cannot imply some of the logics to optimal > components, but tomorrow they will be able to. > > Having said so much about generic HDL, I also insist that HDL designers > should know what exactly they are designing. Sometimes what the > synthesizers generate is not what you really want, in which case you > have to step in. > > -jzArticle: 80713
Marc, See my other postings. Only trying to make one simple point here. As Paul points out (correctly), the tools try to fit generic HDL into the special structures (or else why would we even try to put them in). Often the tools can't make the best, and most clever use of the device specific features, until a number of years have gone by, and the tools have been improved to that point. After a number of years, we (as FPGA IC designers) are onto the generation after the next generation .... Austin Marc Randolph wrote: > Austin Lesea wrote: > >>Mike Treseler wrote: >> >>>Austin Lesea wrote: >>> >>>>If you know you are going to use part A, or part X, you will then > > use > >>>>the powerful built in features that each vendor offers. >>> >>>Many do, but I don't. >>>If the feature can't be inferred from code >>>for both vendors, I'd rather not use it. >> >>Mike, >> >>Then you are not a high end user. > > > How silly. > > You can infer DDR registers, shift-registers (which map flawlessly to > SRLs), and even a number of math functions (which map to the latest V4 > DSP48 blocks). What else does it take to meet your criteria of being > be a high-end user? > > Have fun, > > Marc >Article: 80714
Paul, I posted what the worst case was (more than a week ago). If you are using our parts, and you want to know, your FAE can tell you everything, including plots from thousands of parts, over all the corners. In other news -- "Virtex-4 FPGA Availability: Virtex-4 LX25, LX60, LX100, SX35, SX55, and FX12 are shipping today. Xilinx now has a total of 14 FPGAs in production at 90nm, more than three times the number of its nearest competitor." AustinArticle: 80715
Parag, I think that you took a giant leap in your learning process and it didn't quite work right. Trying to debug the problem from this point would be a very lengthy process. I would suggest that you start out with the shipped design files first and go through the "Creating a Linux BSP and System Image" tutorial first. http://www.xilinx.com/products/boards/ml310/current/reference_designs/base/linux/ml310_base_linux_bsp_proj_creation.pdf After you have this flow understood and working, then go ahead and build your new system. Ed beeraka@gmail.com wrote: > Hi.. > Has anyone been able to download their own bitfile (other than > ..ml310_pci_bootloop.bit) and run linux (by downloading the elf file ) > using xmd... > > > What I did in generating my bit file is opened up EDK and then > added up my own core (an OPB core indeed ) changed the settings in > Software Platform to include linux_mvl31 for ppc405_0 and set the > parameters in Library / OS parameters ..Then I generated the > libraries...Then I obtained the download.bit file (which includes a > bootloop indeed )..I downloaded the bit file using iMPACT on to the ML > 310 and then downloaded the linux kernel Image elf file using XMD ..but > I dont find any change on the serial port terminal..... > > So If anyone had success in doing this stuff then please help me > out guys..... > > Thanks in advance........ > -- > Parag Beeraka >Article: 80716
So defenately no SW error,
after 3 days of searching, it appears i had overlooked a dcm parameter,
now i feel kind a stupid, but anyway, it is solved
for future references,
make sure ocm and ppc clock is an integer multiple of 4 and it works,
don't confuse the following like I did .. I didn't noticed it until now
PARAMETER C_CLKFX_DIVIDE
PARAMETER C_CLKDV_DIVIDE
2 letters diff is something you can miss easely , but can mean 3 days of
being an ass to the whole world, ah well
"Mindroad" <mindroad@hotmail.com> schreef in bericht
news:422f0b10$0$10333$ba620e4c@news.skynet.be...
> Well yesterday I tried something like :
>
> const XIo_Address sflag_PORT = XPAR_DSBRAM_IF_CNTLR_0_BASEADDR + 0;
> Xuint32 sflag;
>
> sflag = XIo_In32( (XIo_Address)sflag_PORT);
>
> putnum(sflag);
>
>
> //////////////////////////////////////
> it still hangs :(
>
> is there someone that encountered this problem .. because the above I
almost
> copy pasted out of an example code
> thx in advance !
>
>
> "Mindroad" <mindroad@hotmail.com> schreef in bericht
> news:422dfa37$0$20677$ba620e4c@news.skynet.be...
> > Hi,
> >
> > After I builded my design in EDK and made a toplevel VHDL in ISE, I
> started
> > writing code for both PPC on my V2P20 ... the first PPC serves as an
> > Communication unit which transfers data in between memories, accessible
by
> > external device ... I have no problem whatsoever accessing these
memories,
> > either on opb or plb busses
> > When I started the part of interconnecting the two PPC with a BRAM
memory
> > using DSOCM I encountered the following problem, which up to know I
cannot
> > solve (this is the first time I design on FPGA) ...
> >
> > To access the BRAM from the first PPC serving as Comm Unit I used the
code
> > which worked for accessing memories on the PLB since I suppose the
> > addressing of memories is always in the same way, as if we address one
big
> > memory
> >
> > code :
> > Xuint32 * bram_Ptr = XPAR_BRAM_BASE_ADDR;
> > Xuint32 value = *bream_Ptr;
> >
> > When I download the bit file on the FPGA, the system hangs, when
executing
> > these commands
> >
> > can someone help me with this problem, I spend some time looking for the
> > solution and I found some macros in xio.h, but I have no clue how to use
> > them, and when I look into application notes, it appears nothing is ever
> > said about how accessing BRAM, so it must be straightforward
> >
> > thx in advance
> >
> > could be I miss some parameters or connections in the MHS file, but I
> doubt
> > it since all should almost be set by default
> >
> > BEGIN dsocm_v10
> > <--- connected to the PPC405 through bus interface
> > PARAMETER INSTANCE = dsocm_v10_0
> > PARAMETER HW_VER = 2.00.a
> > PARAMETER C_DSCNTLVALUE = 0x85
> > PORT DSOCM_Clk = sys_clk
> > PORT sys_rst = sys_rst_l
> > END
> >
> > BEGIN dsbram_if_cntlr
> > PARAMETER INSTANCE = dsbram_if_cntlr_0
> > PARAMETER HW_VER = 3.00.a
> > PARAMETER C_BASEADDR = 0xF0000000
> > PARAMETER C_HIGHADDR = 0xF0001fff
> > BUS_INTERFACE DSOCM = dsocm_v10_0
> > BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
> > END
> >
> > BEGIN bram_block
> > PARAMETER INSTANCE = bram_block_0
> > PARAMETER HW_VER = 1.00.a
> > BUS_INTERFACE PORTA = dsbram_if_cntlr_0_porta
> > BUS_INTERFACE PORTB = dsbram_if_cntlr_1_porta
> > END
> >
> >
> >
> >
> > could be I made some mistake in my linker script :
> >
> > _STACK_SIZE = 1k;
> > _DOCM_SIZE = 8k;
> >
> > MEMORY
> > {
> > plb_bram_if_cntlr_1_bram : ORIGIN = 0xFFFF0000, LENGTH = 16K
> > plb_bram_if_cntlr_2_bram : ORIGIN = 0xFFFF8000, LENGTH = 32K
> > dsbram_if_cntlr_0_porta : ORIGIN = 0xF0000000, LENGTH = 8K
> > }
> > ...
> >
> >
>
>
Article: 80717Jason Zheng wrote: (snip) > I'm a big supporter of using generic HDL, because it makes your design > portable. It's portable not just in a sense that you can synthesize the > design on different platforms TODAY, but also that you can easily apply > it to TOMORROR's hardware. Portability is one of the big philosophies > behind the UNIX movement (and yes that is software, but the idea is the > same). Without it, UNIX wouldn't have survived past PDP-11. > My point is, utilizing some special features may get you 20% more > performance today. But next year, some other vendor might come up with a > good platform that runs 50% faster than your current vendor's platform. > If you use generic HDL, very little, if any, efforts are needed to move > on to the better technology or platform. Whereas specialized HDL designs > will soon require too much effort to keep up with the new technology. Following the unix analogy, where some low level parts might be written in assembly, write the generic HDL, and then replace specific modules with custom versions to get the extra performance. -- glenArticle: 80718
Glen, Good idea. Don't work too hard. Let the synthesis tools to their best, and then see where they did not do what they "could" have to get the best performance. This is something that our FAE's help our customers with all the time: getting that last little bit out of the design (so that they may buy a smaller part, or a slower part, and save $$). Austin glen herrmannsfeldt wrote: > Jason Zheng wrote: > (snip) > >> I'm a big supporter of using generic HDL, because it makes your design >> portable. It's portable not just in a sense that you can synthesize >> the design on different platforms TODAY, but also that you can easily >> apply it to TOMORROR's hardware. Portability is one of the big >> philosophies behind the UNIX movement (and yes that is software, but >> the idea is the same). Without it, UNIX wouldn't have survived past >> PDP-11. > > >> My point is, utilizing some special features may get you 20% more >> performance today. But next year, some other vendor might come up with >> a good platform that runs 50% faster than your current vendor's >> platform. If you use generic HDL, very little, if any, efforts are >> needed to move on to the better technology or platform. Whereas >> specialized HDL designs will soon require too much effort to keep up >> with the new technology. > > > Following the unix analogy, where some low level parts might be written > in assembly, write the generic HDL, and then replace specific modules > with custom versions to get the extra performance. > > -- glen >Article: 80719
backhus escribió: > > > Hi Adrian > >> Number of occupied Slices: 2,625 out of >> 1,920 136% >> (OVERMAPPED) > > > This part of your design report shows that the core does not fit into > the X3S200 device. > With some luck you can use different synthesis constraints and higher > efforts for the mapping and PAR to reduce the number of occupied Slices. > > Have a nice synthesis > Eilert > Hi Eilert, Tnankyou for your reply. How can I configure EDK for using other/better synthesis constraints and higher efforts? Thankyou.Article: 80720
Hello ALL, I am designing device, based on Virtex-4 FX20 chip. This device is going to produce lots of data and I would like to send it to processing computer using Gigabit Ethernet interface. I am lucky to have two Ethernet MAC's built-in in the FPGA. Also we would like to use RocketIO transceivers to connect our Ethernet MAC's to physical media. Here is my problem begins. I need to connect magnetic to RocketIO differential outputs. I have searched Xilinx web-site, but found nothing about this issue. There are two user guides, one about Tri-mode Ethernet MAC and another about RocketIO MGT. Both guides full of useful information, but none of them highlights this issue. They just cross-reference each other on this matter :) So, does any one has any experience in putting Ethernet MAC (hardware or IP Core) and RocketIO transceiver to work together in Gigabit Ethernet configuration (without using external PHY)? Xilinx web-site has an Answer Record 13928, stating full compliance Virtex-2 Pro RocketIO MGT to all Gigabit Ethernet standards, so I assume Virtex-4 MGT is compliant to all Gigabit Ethernet standards as well. With best regards, Vladimir S. MirgorodskyArticle: 80721
Austin Lesea wrote: > Jason, > > All very good points. > > My point was simply that a power user trying to get the last 2 ps out of > their design usually ends up using the features specific to that part, A > or X. > > By doing so they often can use a lower speed grade part, or a smaller > part, and save a lot of money. > > (No offense intended to anyone). > > Austin > Austin, No offense, but would you please stop top-posting on news groups? Bottom-posting is easier to read, especially when quoting several responses. This website has more explanations on why: http://www.caliburn.nl/topposting.html JasonArticle: 80722
Vladimir, I apologize, but this answer record is misleading. There are two different physical types of Gigabit Ethernet, the Base-T versions and the Base-X versions. What you are describing is that you want to implement a 1000-Base-T which is a RJ45 connector and CAT5/5e/6 cable and you can not do this directly from a RocketIO MGT. The RocketIO MGTs are electrically and physically compliant to the Base-X versions (SX/LX), but not the Base-T version. If you want to drive Base-T and you want to drive it with a RocketIO MGT, then you need to use it configured as a SGMII interface either to a discrete 1000-Base-T Phy (less expensive), or to a SFP cage with a 1000-Base-T module (more expensive) instead of the normal SFP optical module. I will get this answer record updated to clarify the supported modes. Ed v_mirgorodsky@yahoo.com wrote: > Hello ALL, > > I am designing device, based on Virtex-4 FX20 chip. This device is > going to produce lots of data and I would like to send it to processing > computer using Gigabit Ethernet interface. I am lucky to have two > Ethernet MAC's built-in in the FPGA. Also we would like to use > RocketIO transceivers to connect our Ethernet MAC's to physical > media. Here is my problem begins. I need to connect magnetic to > RocketIO differential outputs. I have searched Xilinx web-site, but > found nothing about this issue. There are two user guides, one about > Tri-mode Ethernet MAC and another about RocketIO MGT. Both guides full > of useful information, but none of them highlights this issue. They > just cross-reference each other on this matter :) > > So, does any one has any experience in putting Ethernet MAC (hardware > or IP Core) and RocketIO transceiver to work together in Gigabit > Ethernet configuration (without using external PHY)? Xilinx web-site > has an Answer Record 13928, stating full compliance Virtex-2 Pro > RocketIO MGT to all Gigabit Ethernet standards, so I assume Virtex-4 > MGT is compliant to all Gigabit Ethernet standards as well. > > With best regards, > Vladimir S. Mirgorodsky >Article: 80723
glen herrmannsfeldt wrote: > Jason Zheng wrote: > (snip) > >> I'm a big supporter of using generic HDL, because it makes your design >> portable. It's portable not just in a sense that you can synthesize >> the design on different platforms TODAY, but also that you can easily >> apply it to TOMORROR's hardware. Portability is one of the big >> philosophies behind the UNIX movement (and yes that is software, but >> the idea is the same). Without it, UNIX wouldn't have survived past >> PDP-11. > > <snip> > > Following the unix analogy, where some low level parts might be written > in assembly, write the generic HDL, and then replace specific modules > with custom versions to get the extra performance. > > -- glen > True about the low-level assembly part, but you missed the point. Minimizing, not celebrating, such low-level components is the reason for Unix's succsess. On a side note, one of the trends in OS development is to shrink the kernel and to standardize the kernel interface. All of that makes it easier to port application programs from one unix system to another. It is true that you cannot avoid doing low-level stuff in either software or hardware design. But the less you have to think in the lower-level abstraction layer, the more time you can spend in improving the high-level architecture. -jzArticle: 80724
Paul Leventis wrote:
> The synthesis tools are pretty good at inferring multipliers/MACs from
> HDL, as well as other higher-level primitives.
Don't tell anyone, but the generic synthesis templates
born in Leo and Synplicity are getting covered
by XST and Quartus as well.
The multiplier/accumulator templates work. Block RAM/ROM
and the FIFO style dual-port RAM has worked for
years. Carry-chain counters, shifters, state sequencers, etc
work for just about any reasonable description.
The black box list is getting quite small.
PLLs and full dual-port rams are all that
come to mind.
> So your "vanilla"
> approach to design may still take advantage of some of the hard blocks
> available.
Yes, I would say most. I am a bit baffled to
find a use for multipliers in non-dsp applications.
Maybe I should be calculating Pi as a background process :)
> I should point out that you should see very good performance in
> Stratix-II without any architecture-specific coding. Quartus will
> automatically balance multipliers between LEs and DSP blocks, and also
> automatically handles the mapping of generic RAMs into the three
> available RAM types in the device. We like to make things as easy as
> we can on our users, otherwise these features would go unused in many
> designs!
Quartus synthesis wins my most-improved award.
It was once the worst vhdl synthesis on the planet.
Now it handles all my code just fine.
I use leo mainly because it is faster, covers
all the devices and has a better rtl viewer.
-- Mike Treseler
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