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
What do you recommendation for serial communications between FPGA chips? We= have one FPGA sending configuration information to multiple other FPGAs. T= he FPGAs will be on different boards. The bandwidth is low, although the me= ssage transfer needs to be accomplished in well under a microsecond. We hav= e a limited number of lines, so an addressable serial scheme is desirable.= =20 Previously we have "rolled our own" asynchronous serial protocol and corres= ponding firmware, and transmitted via LVDS. The drawbacks are that a lot of= effort went into both developing the firmware, and solving signal integrit= y challenges. I'm wondering what common practices or standard solutions exist? With the g= eneric transceivers now available, what out-of-the box techniques are there= for using them? Are there cookbook approaches to designing the signal circ= uitry? SRIO seems like just the solution, but I really can't tell if it is = straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO co= re is huge). Thanks for your thoughts, CharlieArticle: 156251
On 24/01/2014 16:05, Charlie Martin wrote: > What do you recommendation for serial communications between FPGA chips? We have one FPGA sending configuration information to multiple other FPGAs. The FPGAs will be on different boards. The bandwidth is low, although the message transfer needs to be accomplished in well under a microsecond. We have a limited number of lines, so an addressable serial scheme is desirable. > > Previously we have "rolled our own" asynchronous serial protocol and corresponding firmware, and transmitted via LVDS. The drawbacks are that a lot of effort went into both developing the firmware, and solving signal integrity challenges. > > I'm wondering what common practices or standard solutions exist? With the generic transceivers now available, what out-of-the box techniques are there for using them? Are there cookbook approaches to designing the signal circuitry? SRIO seems like just the solution, but I really can't tell if it is straightforward to integrate (e.g. the API for the Xilinx Serial RapidIO core is huge). > > Thanks for your thoughts, > Charlie > Not quite enough timing info to know if this is a good bet but I would start with SPI, then move to SPI via LVDS, then 4 data line SPI over LVDS - should be good for 12Mbyte/s easily (nice slow 25MHz clock) but could possibly get up to 50Mbyte/s. But if you are seriously contemplating SRIO then you are perhaps hoping for an order faster than this which would be way out of my league. Michael KellettArticle: 156252
John Larkin wrote: > > All that DDRx ram and microSim and Ethernet and stuff is a nuisance to > design and test. For a tad under $200, it's a bargain. Nice. Not as nice and cheap as the Parallella board, but at least you can already buy it. -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 156253
Charlie Martin <tickranch@gmail.com> wrote: > I'm wondering what common practices or standard solutions exist? With the > generic transceivers now available, what out-of-the box techniques are > there for using them? Are there cookbook approaches to designing the > signal circuitry? SRIO seems like just the solution, but I really can't > tell if it is straightforward to integrate (e.g. the API for the Xilinx > Serial RapidIO core is huge). If you're on Xilinx, have a look at Aurora for the physical layer. I haven't used it but it looks a useful building block for a bits-in, bits-out solution. The things you have to worry about (in the general case) are: Crossing clock domains (one transmit clock, plus a clock per receive lane) Line encoding (8b/10b, 128b/130b or similar) Stuffing idle symbols when you don't have any data PLLs and clocking (locking receiver clock on startup, plus handling powerdown if you ever do that) Packetisation/reassembly/alignment Error checking/correction/retransmits I don't have any experience with RapidIO, but I think it's either that or roll your own solution (as we did). Most of the other serial formats (ethernet etc) have too high latency. TheoArticle: 156254
On Sat, 25 Jan 2014 00:05:11 +0100, Frank Buss <fb@frank-buss.de> wrote: >John Larkin wrote: >> >> All that DDRx ram and microSim and Ethernet and stuff is a nuisance to >> design and test. For a tad under $200, it's a bargain. > >Nice. Not as nice and cheap as the Parallella board, but at least you >can already buy it. $99 is amazing for that board. One can ignore the Epiphany thing, I guess. -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 156255
Il giorno gioved=EC 4 febbraio 2010 18:02:49 UTC+1, John Adair ha scritto: > It's not been tried on a Linux system here as yet but as it is driver > compatible with the Xilinx cable there is a good chance it will work > anywhere their cable or software works (with the usual Linux > restrictions). >=20 > John Adair > Enterpoint Ltd. >=20 > On 4 Feb, 16:40, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com> wrote: > > >Prog3 operates with Xilinx software and does not need anything else to > > >use this programmer. > > > > >John Adair > > >Enterpoint Ltd. > > > > Does it run under linux? > > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com Yes it does, I am using it with ubuntu 12.04, with cable drivers. It works perfectly. If you need more hints I'll be glad to let you know how to install cable dr= ivers and etc..Article: 156256
On Wednesday, February 6, 2008 11:31:22 PM UTC-8, mh wrote: > On Feb 4, 7:22 pm, posedg...@yahoo.com wrote: > > > I myself was confronted with such a situation and I asked this > > > > > question on this forum, and was contacted by S3 group who later sent > > > me the tool. I used it and found it an excellent tool. > > > HTH > > > > Seems the unmodified tool is still missing on the S3 site:http://www.s3group.com/system_ic/gnat/download_gnat/ > > > > Could you upload it somewhere? > > > > Hi, > I had a correspondence with S-3 group and they allowed me to freely > distribute Gnat tool with a comment that they don't support this tool > any more. > > So, Any one who need this tool may contact me directly. > > /MHArticle: 156257
MH or anyone who still has a copy of the GNAT tool, please post a link for me (and others). Much appreciated! V > > Hi, > I had a correspondence with S-3 group and they allowed me to freely > distribute Gnat tool with a comment that they don't support this tool > any more. > > So, Any one who need this tool may contact me directly. > > /MHArticle: 156258
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andy, my apologies for such a delayed reply. On 1/22/2014 1:27 AM, jonesandy@comcast.net wrote: [] > Most "automatic" conversion of logic from LUTs to RAMs involves > using the RAMs like ROMs, preloaded with constant data during > configuration. Flash based FPGAs from MicroSemi do not have the > ability to preload their BRAMs during "configuration." There is no > "configuration" phase at/during startup during which they could > automatically be preloaded. That is quite a good piece of information. So I can stop looking for any 'automatic' mode. Moreover any RAM logic I may profit of would need to be configured after power up via external commands. While this is certainly possible, it requires system modifications which are not so often welcome. [] > If you have several identical slow speed interfaces (e.g. UARTs, > SPI, I2C, etc.) that could happily run with an effective clock rate > of a fraction of your system clock rate, look at C-slow > optimization to reduce utilization. There are a few coding tricks > that ease translating a single-channel module into a multi-channel, > C-slowed module capable of replacing multiple copies of the > original. Thanks for the hint. The way I understood this is inserting say 2 registers for each register, increasing latency without affecting the functionality, but allowing retiming. I haven't understood why they call it /C/-slowing and why /C/-registers... > Retiming can be combined with C-slowing (the two are very > synergystic) to enable the original clock rate to be increased, > recovering some of the original per-channel performance. > > Repipelining can be combined with C-slowing (also synergystic) to > hide original design latency, thus recovering some of the > per-channel performance without increasing the system clock rate. These techniques seem indeed attractive when it comes to speed optimization, but in my specific case I simply wanted to free some core logic usage to allow other functionality to be added to the design. Since these 'features' are given at such a later stage in the design phase, it seems very unlikely it will not require an architectural change. That's the main reason why I was looking at some 'automatic' feature to profit of onboard resources without the need to change too much RTL. I guess there's no easy fix for this. Al -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS48IPAAoJEPaNonZWXERQgW0IAORzqR8iX68j9u+QZEjZ67ID C3eHGLk4LddDtrX+Uf2TOYoxH0OV1gvMHqrPdbEg83sBrQtSK62ScnKLNpNnQL7y ViOnBxuyMn3IbJEp7L7MV31WjFUnhX+k4eUiRMAAEUnOUVIp5VFxlb1eUPqZr/XG KlLRKw1+a3X1i1UaO2SjlIx+p1/JVZ4fvDb+HWALnbdwFE2edktf/6APl0bee8gB sOWdTIS88NDscSZtjZBokFIOPDGoo95lOdx2bioR4WYeckZdMyOFjStrzKcDQaZb tjZKUisyeyOIkjlVur4Vso4XaG4oK+adJgNTq30B2beF+LJkx+cA1soFZgxn5WA= =qYUI -----END PGP SIGNATURE-----Article: 156259
alb <alessandro.basili@cern.ch> wrote: (snip) (snip) > Thanks for the hint. The way I understood this is inserting say 2 > registers for each register, increasing latency without affecting the > functionality, but allowing retiming. I haven't understood why they > call it /C/-slowing and why /C/-registers... I only learned about C-slow a year or two ago, and wasn't sure why it was so different from the pipelining that computer designers did in the 1960's and 1970's. And yes, I don't know what the C is for. -- glenArticle: 156260
>> Nice. Not as nice and cheap as the Parallella board, but at least you >> can already buy it. > $99 is amazing for that board. One can ignore the Epiphany thing, I > guess. Can one? What would I need to access the FPGA fabric? Assuming I ever get my board... I suppose I'll need to acquire some recent Xilinx IDE. -- mac the naïfArticle: 156261
John Larkin <jlarkin@highlandtechnology.com> writes: > On Sat, 25 Jan 2014 00:05:11 +0100, Frank Buss <fb@frank-buss.de> > wrote: > >>John Larkin wrote: >>> >>> All that DDRx ram and microSim and Ethernet and stuff is a nuisance to >>> design and test. For a tad under $200, it's a bargain. >> >>Nice. Not as nice and cheap as the Parallella board, but at least you >>can already buy it. > > $99 is amazing for that board. One can ignore the Epiphany thing, I > guess. The "Epiphany thing" sounds like what you have been advocating, for the last few years. Many cores, a core for each task etc. Now you can *buy* one, you are not interested? :) -- John DevereuxArticle: 156262
From what I understand, C-slowing originated as a state-space transform. I = don't know what C stands for either. The earliest reference I have seen for its application to digital circuits = is: C. Leiserson, F. Rose, and J. Saxe, "Optimizing synchronous circuitry by re= timing," Proceedings of the 3rd Caltech Conference On VLSI, pp. 87-116, Mar= ch 1983 I do not have access to the paper, but it is cited in many later papers as = the initial work in the application of C-slowing to digital circuits. From = the title, I would assume that they employed C-slowing to remove all single= -clock-cycle feeback paths, which otherwise cannot be retimed. AndyArticle: 156263
Hi, I'm programming the Flash memory in a Digilent "S6 carrier" board. It takes a long time, about 8 minutes. The configuration file size is 1484404 bytes and I'd expect it to take around 10s at a cable clock frequency of 1.6 Mbit/s. Not 467s. Under "edit attached flash properties" there is an option "Data width: 1". What does this mean? If I set it to the maximum of 4, I get a warning >> "The data width you assigned is 4 but the PROM file (.mcs) is generated in a x1 mode. Please double-check your assignments or it may not work properly." but I don't see any options when the .mcs file is created to change that. The Flash memory is N25Q128, and the electrical connections can be found here, top of page 5: http://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf What does this option mean? A log from an upload is pasted below. I've tried to create the .mcs file for smaller memory (16M instead of 128M) but it seems to make no difference. Is there anything I can do to speed this up? With my favourite "Papilio Pro board", reflashing takes about 10 s (the bitstream is 1/6 the size, but still...) Verify is off. Direct upload to the FPGA is of course an option, but it's one thing less to worry if I can take the board off the shelf after a week and simply plug it in. Cheers Markus INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.3 INFO:iMPACT - Digilent Plugin: Opening device : "SN:xxx". INFO:iMPACT - Digilent Plugin: User Name: FMC-Carrier-S6 INFO:iMPACT - Digilent Plugin: Product Name: FMC Carrier-S6 INFO:iMPACT - Digilent Plugin: Serial Number: xxx INFO:iMPACT - Digilent Plugin: Product ID: 00F0000D INFO:iMPACT - Digilent Plugin: Firmware Version: 0306 INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0 INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 1600000 Hz INFO:iMPACT - Current time: 29.01.2014 15:17:36 PROGRESS_START - Starting Operation. Maximum TCK operating frequency for this device chain: 0. Validating chain... Boundary-scan chain validated successfully. '1': SPI access core not detected. SPI access core will be downloaded to the device to enable operations. INFO:iMPACT - Downloading core file C:/Xilinx/14.7/ISE_DS/ISE/spartan6/data/xc6slx45_spi.cor. '1': Downloading core... LCK_cycle = NoWait. LCK cycle: NoWait done. '1': Reading status register contents... INFO:iMPACT:2219 - Status register values: INFO:iMPACT - 0011 1100 1110 1100 INFO:iMPACT:2492 - '1': Completed downloading core to device. '1': IDCODE is '20ba18' (in hex). '1': ID Check passed. '1': IDCODE is '20ba18' (in hex). '1': ID Check passed. '1': Erasing Device. '1': Using Sector Erase. '1': Programming Flash. '1':Programming in x1 mode. '1': Programmed successfully. INFO:iMPACT - '1': Flash was programmed successfully. LCK_cycle = NoWait. LCK cycle: NoWait INFO:iMPACT - '1': Checking done pin....done. '1': Programmed successfully. PROGRESS_END - End Operation. ************** Elapsed time = 466 sec. ***************** --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156264
mnentwig wrote: > Hi, > > I'm programming the Flash memory in a Digilent "S6 carrier" board. It takes > a long time, about 8 minutes. > > The configuration file size is 1484404 bytes > and I'd expect it to take around 10s at a cable clock frequency of 1.6 > Mbit/s. Not 467s. > Unfortunately there's a lot of overhead in programming the SPI flash, so the cable bit rate is not the bitstream data rate. 8 minutes may be about right. Depending on the cable, you might up the bit rate to 12 MHz (requires a USB 2.0 HS slot). I've found that many BIOSes default to setting the USB 2.0 ports to standard speed or "fast" rather than high-speed. You'd need to open the BIOS setup to see if that's a problem on your computer. > > > Under "edit attached flash properties" there is an option "Data width: 1". > What does this mean? > If I set it to the maximum of 4, I get a warning > >>> "The data width you assigned is 4 but the PROM file (.mcs) is generated > in a x1 mode. Please double-check your assignments or it may not work > properly." > > but I don't see any options when the .mcs file is created to change that. > The Flash memory is N25Q128, and the electrical connections can be found > here, top of page 5: > http://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf > What does this option mean? > This is the way the SPI flash is read. Most modern SPI flash chips support dual or quad readout mode (x2 or x4). This makes the time to configure the FGPA from flash go down by half or quarter from the standard SPI serial (x1) time. However the bitstream must match the data width of the PROM file. To use x4 mode, you need to have an appropriate SPI device that supports it, e.g. Winbond W25Qxxx. Then you have to go back to ISE and set the bit width to 4 when you generate the bitstream (note - this is not done from Impact). Finally when you generate the .mcs file, you need to select the x4 mode. In any case this only reduces the startup time of the FPGA. It has no effect on the time to program the Flash. Programming is always done 1-bit serially. > > > A log from an upload is pasted below. > I've tried to create the .mcs file for smaller memory (16M instead of 128M) > but it seems to make no difference. > > Is there anything I can do to speed this up? With my favourite "Papilio Pro > board", reflashing takes about 10 s (the bitstream is 1/6 the size, but > still...) > Verify is off. > > Direct upload to the FPGA is of course an option, but it's one thing less > to worry if I can take the board off the shelf after a week and simply plug > it in. > > Cheers > > Markus > > INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.3 > INFO:iMPACT - Digilent Plugin: Opening device : "SN:xxx". > INFO:iMPACT - Digilent Plugin: User Name: FMC-Carrier-S6 > INFO:iMPACT - Digilent Plugin: Product Name: FMC Carrier-S6 > INFO:iMPACT - Digilent Plugin: Serial Number: xxx > INFO:iMPACT - Digilent Plugin: Product ID: 00F0000D > INFO:iMPACT - Digilent Plugin: Firmware Version: 0306 > INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0 > INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 1600000 Hz > INFO:iMPACT - Current time: 29.01.2014 15:17:36 > PROGRESS_START - Starting Operation. > Maximum TCK operating frequency for this device chain: 0. > Validating chain... > Boundary-scan chain validated successfully. > '1': SPI access core not detected. SPI access core will be downloaded to > the device to enable operations. > INFO:iMPACT - Downloading core file > C:/Xilinx/14.7/ISE_DS/ISE/spartan6/data/xc6slx45_spi.cor. > '1': Downloading core... > LCK_cycle = NoWait. > LCK cycle: NoWait > done. > '1': Reading status register contents... > INFO:iMPACT:2219 - Status register values: > INFO:iMPACT - 0011 1100 1110 1100 > INFO:iMPACT:2492 - '1': Completed downloading core to device. > '1': IDCODE is '20ba18' (in hex). > '1': ID Check passed. > '1': IDCODE is '20ba18' (in hex). > '1': ID Check passed. > '1': Erasing Device. > '1': Using Sector Erase. > '1': Programming Flash. > '1':Programming in x1 mode. > '1': Programmed successfully. > INFO:iMPACT - '1': Flash was programmed successfully. > LCK_cycle = NoWait. > LCK cycle: NoWait > INFO:iMPACT - '1': Checking done pin....done. > '1': Programmed successfully. > PROGRESS_END - End Operation. > ************** Elapsed time = 466 sec. ***************** > > > --------------------------------------- > Posted through http://www.FPGARelated.com -- GaborArticle: 156265
Hi Gabor, thanks for the explanation. I'll try a different USB port tomorrow, didn't think of that. I may have plugged it into a mouse-/keyboard port, not the USB 3.0 socket. I was also wondering about the startup time, not that it's a problem in my application. About 5 secs, seemed rather slow. Might give it a shot and set 4x mode, just out of curiosity. Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156266
mnentwig wrote: > Hi Gabor, > > thanks for the explanation. > I'll try a different USB port tomorrow, didn't think of that. I may have > plugged it into a mouse-/keyboard port, not the USB 3.0 socket. > I was also wondering about the startup time, not that it's a problem in my > application. About 5 secs, seemed rather slow. Might give it a shot and set > 4x mode, just out of curiosity. > > Cheers > > Markus > > --------------------------------------- > Posted through http://www.FPGARelated.com While going to x4 mode definitely speeds things up, 5 seconds does sound like a long time unless you're using a very large part. Options for the SPI clock speed are also bitgen parameters. The default CCLK rate is rather slow, 2 MHz IIRC. You can set this as high as the actual flash part can go, but you need to take into account the wide (+/- 50% IIRC) frewuency tolerance of the internally generated CCLK. So while going to x4 mode increases config speed by a factor of 4, increasing the clock speed from default could give up to a factor of 50 for newer FPGA families and SPI parts. Doing both can speed things up by as much as 200 times. -- GaborArticle: 156267
Hi Guys, I am currently working on FPGA accelerators for PathFinder algorithm (FPGA = routing algorithm). I am planning to use a HW/SW co-design to speedup the a= lgorithm but I need a C code implementation of the PathFinder to start with= since my project is to accelerate the algorithm in FPGA and I don't have e= nough time to implemented from scratch. I appreciate your help if you can g= ive me the c code or tell me where I can get it. thanks, ZiadArticle: 156268
On Friday, January 31, 2014 6:37:13 PM UTC-5, ZIAD ABUOWAIMER wrote: >=20 > I am currently working on FPGA accelerators for PathFinder algorithm (FPG= A routing algorithm). I am planning to use a HW/SW co-design to speedup the= algorithm but I need a C code implementation of the PathFinder to start wi= th since my project is to accelerate the algorithm in FPGA and I don't have= enough time to implemented from scratch. I appreciate your help if you can= give me the c code or tell me where I can get it. >=20 Try this link for sources... http://lmgtfy.com/?q=3Dpathfinder+source+code I'd suggest taking the first link from that list and read. KevinArticle: 156269
Hi, I've got some FPGA resources that are shared, for example RAM and multiplier. Instead of explicitly muxing the inputs, would it make sense to use "virtual" tristate ports in connected modules? I'd expect that if the enabling condition is the same as in an explicit mux, also the resulting implementation should be the same. Or not? I haven't started any synthesis experiments yet, thought I'd ask first (even though we all know that a couple of months in the lab can save many hours in the library...) Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156270
mnentwig <24789@embeddedrelated> wrote: (snip) > I've got some FPGA resources that are shared, for example RAM and > multiplier. > Instead of explicitly muxing the inputs, would it make sense to use > "virtual" tristate ports in connected modules? > I'd expect that if the enabling condition is the same as in an explicit > mux, also the resulting implementation should be the same. Or not? Early FPGAs had real tristate lines inside. With scaling, they required buffers along the way, and so most now have, as you note, virtual tristates. (Except that I/O buffers usually have real tristate, going off chip.) As well as I know, virtual tristates are implemented as either virtual wired-AND or wired-OR. (In TTL terms, open collector or its complement.) That is probably more efficient than an actual MUX. In verilog (and I presume VHDL) you can implement wired-AND or wired-OR, and it likely synthesizes just fine. At some point, you should design for readability first, and let the tools do their job. If the logic looks like tristate, where the enables are available at the driving points, then virtual tristate, virtual wired-AND, or virtual wired-OR are probably best. If the select line is available close to the destination, then MUX is probably best. Hope this helps, -- glenArticle: 156271
On Saturday, February 1, 2014 9:14:18 AM UTC-5, KJ wrote: > On Friday, January 31, 2014 6:37:13 PM UTC-5, ZIAD ABUOWAIMER wrote: >=20 > >=20 >=20 > > I am currently working on FPGA accelerators for PathFinder algorithm (F= PGA routing algorithm). I am planning to use a HW/SW co-design to speedup t= he algorithm but I need a C code implementation of the PathFinder to start = with since my project is to accelerate the algorithm in FPGA and I don't ha= ve enough time to implemented from scratch. I appreciate your help if you c= an give me the c code or tell me where I can get it. >=20 > >=20 >=20 >=20 >=20 > Try this link for sources... >=20 > http://lmgtfy.com/?q=3Dpathfinder+source+code >=20 >=20 >=20 > I'd suggest taking the first link from that list and read. >=20 >=20 >=20 > Kevin And every single link on the first page at least is entirely irrelevant. For instance, the first link is broken, but appears to refer to code to com= plete a file name path. Go here: http://www.eecg.toronto.edu/~jayar/software/software.htmlArticle: 156272
On Sat, 01 Feb 2014 15:48:08 -0600 "mnentwig" <24789@embeddedrelated> wrote: > Hi, > > I've got some FPGA resources that are shared, for example RAM and > multiplier. > Instead of explicitly muxing the inputs, would it make sense to use > "virtual" tristate ports in connected modules? > I'd expect that if the enabling condition is the same as in an explicit > mux, also the resulting implementation should be the same. Or not? > > I haven't started any synthesis experiments yet, thought I'd ask first > (even though we all know that a couple of months in the lab can save many > hours in the library...) > > Cheers > > Markus > > --------------------------------------- > Posted through http://www.FPGARelated.com Oh good, you've stepped into one of the long running holy wars of FPGA design. Respectfully, I'm going to disagree with Glen. Yes, the tools should be able to infer an AND/OR mux from the logic you wrote as a tristate. But it means that you've knowingly written code that says it does one thing and really does another. To my mind it's... unaesthetic. It breaks the rule that the point of code is to tell you the programmer what's going on, and then it should also synthesize. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 156273
In article <20140203082924.045c791c@rg.highlandtechnology.com>, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >On Sat, 01 Feb 2014 15:48:08 -0600 >"mnentwig" <24789@embeddedrelated> wrote: > >> Hi, >> >> I've got some FPGA resources that are shared, for example RAM and >> multiplier. >> Instead of explicitly muxing the inputs, would it make sense to use >> "virtual" tristate ports in connected modules? >> I'd expect that if the enabling condition is the same as in an explicit >> mux, also the resulting implementation should be the same. Or not? >> >> I haven't started any synthesis experiments yet, thought I'd ask first >> (even though we all know that a couple of months in the lab can save many >> hours in the library...) >> >> Cheers >> >> Markus >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com > >Oh good, you've stepped into one of the long running holy wars of FPGA >design. > >Respectfully, I'm going to disagree with Glen. Yes, the tools should >be able to infer an AND/OR mux from the logic you wrote as a tristate. >But it means that you've knowingly written code that says it does one >thing and really does another. To my mind it's... unaesthetic. It >breaks the rule that the point of code is to tell you the programmer >what's going on, and then it should also synthesize. Agree with Rob here. We just explicity use Wired-Or in our designs for things like this. I don't really see much use in using tristates in RTL code, when assigning to zero (when something's not used/not needed) is just as easy as assigning to 'z'. And as Rob notes, you're stating explicity what the tools are going synthesize. Big note however, if you're using Vivado, the first versions of the tools didn't support Wired-Or/Wired-And. (It's worked fine forever in ISE). I think they've fixed it in a recent release... Regards, MarkArticle: 156274
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: > On Sat, 01 Feb 2014 15:48:08 -0600 > "mnentwig" <24789@embeddedrelated> wrote: (snip) >> I've got some FPGA resources that are shared, for example RAM and >> multiplier. >> Instead of explicitly muxing the inputs, would it make sense to use >> "virtual" tristate ports in connected modules? (snip) > Oh good, you've stepped into one of the long running holy wars > of FPGA design. > Respectfully, I'm going to disagree with Glen. Yes, the tools should > be able to infer an AND/OR mux from the logic you wrote as a tristate. Reading what I wrote again, I did not say that he should use tristate over wired-OR. I mostly suggested he should write for readability. > But it means that you've knowingly written code that says it does one > thing and really does another. To my mind it's... unaesthetic. It > breaks the rule that the point of code is to tell you the programmer > what's going on, and then it should also synthesize. But a large fraction of HDL code says one thing and does another, at least if you look close enough. For one, they implement with LUTs instead of gates. Also behavioral form is even more different from what it actually does, though I mostly try to write structural verilog. Seems that the main difference betweeen tristate and wired-OR is that the chip doesn't overheat if you pull the line in two directions at the same time. That doesn't seem bad to me. I believe that tristate, wired-AND, and wired-OR will all synthesize the same way, such that one should choose based on personal preference or personal aesthetics. (I tried not to emphasize one in the first post.) I am not so sure that an actual MUX will synthesize the same. But the tools are improving all the time, so maybe they do that by now, too. -- glen
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