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
Hello I have few question and if anyone could help me I would be verry greatfull. This is a situation. I have 300MHz signal that I have to drive to the FPGA clock input. That signal I have to connect to the DCM input and from it to generate new 300MHz clock. But what seems to be a problem. It turns out that when I generate DCM from the core generator it's input frequency can't be higher than 250Mhz. Is it possible to do something like this? Divide the input clock singal by 2 and the signal that is get connect to the input of the DCM. And from DCM take the clock that frequency is multiplied by 2. But how to make this? I doub't that I could easely use T-flip-flop. How I chould know that output from T-flip-flop is going to use clock nets. Is the input of DCM always connected to the clock nets so If my synthesis and implementation pass I would know that idea and design are ok? is there any problem that could ocure with this approach? Thanks anyone who read all this untill the end.:) Like I said, I am greatfull for any kind of help. Best regards ZoranArticle: 134451
On Aug 11, 7:48=A0am, Zorjak <Zor...@gmail.com> wrote: > Hello > > I have few question and if anyone could help me I would be verry > greatfull. > > This is a situation. I have 300MHz signal that I have to drive to the > FPGA clock input. That signal I have to connect to the DCM input and > from it to generate new 300MHz clock. But what seems to be a problem. > It turns out that when I generate DCM from the core generator it's > input frequency can't be higher than 250Mhz. > > Is it possible to do something like this? Divide the input clock > singal by 2 and the signal that is get connect to the input of the > DCM. And from DCM take the clock that frequency is multiplied by 2. > > But how to make this? I doub't that I could easely use T-flip-flop. > How I chould know that output from T-flip-flop is going to use clock > nets. Is the input of DCM always connected to the clock nets so If my > synthesis and implementation pass I would know that idea and design > are ok? is there any problem that could ocure with this approach? > > Thanks anyone who read all this untill the end.:) > Like I said, I am greatfull for any kind of help. > > Best regards > Zoran Look at the Libraries Guide for your Xilinx device family. In that guide, the parameters for the DCM are explained, including the precise thing you need: Attribute: CLKIN_DIVIDE_BY_2 Type: BOOLEAN Allowed Values: FALSE, TRUE Default: FALSE Description: Enables CLKIN divide by two features. This input divider is in place to take care of this specific problem: generating clocks from something a little too high speed. Since the reference clock will become 150MHz after the divider, you just have to double back up. No external logic is needed.Article: 134452
On Aug 11, 7:29=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote: > > > can I read from the FIFO and write into it at the same time? when my 2 > > clocks are independent > > Of course you can read and write simultaneously. That's what a FIFO is > there for. Have you ever read any FIFO description? > Peter Alfke Where else can one get information directly from a bona-fide expert on FIFOs? Thanks again for being here, Peter.Article: 134453
On Aug 11, 8:42=A0am, John_H <newsgr...@johnhandwork.com> wrote: > On Aug 11, 7:48=A0am, Zorjak <Zor...@gmail.com> wrote: > > > > > Hello > > > I have few question and if anyone could help me I would be verry > > greatfull. > > > This is a situation. I have 300MHz signal that I have to drive to the > > FPGA clock input. That signal I have to connect to the DCM input and > > from it to generate new 300MHz clock. But what seems to be a problem. > > It turns out that when I generate DCM from the core generator it's > > input frequency can't be higher than 250Mhz. > > > Is it possible to do something like this? Divide the input clock > > singal by 2 and the signal that is get connect to the input of the > > DCM. And from DCM take the clock that frequency is multiplied by 2. > > > But how to make this? I doub't that I could easely use T-flip-flop. > > How I chould know that output from T-flip-flop is going to use clock > > nets. Is the input of DCM always connected to the clock nets so If my > > synthesis and implementation pass I would know that idea and design > > are ok? is there any problem that could ocure with this approach? > > > Thanks anyone who read all this untill the end.:) > > Like I said, I am greatfull for any kind of help. > > > Best regards > > Zoran > > Look at the Libraries Guide for your Xilinx device family. > > In that guide, the parameters for the DCM are explained, including the > precise thing you need: > > Attribute: CLKIN_DIVIDE_BY_2 > Type: BOOLEAN > Allowed Values: FALSE, TRUE > Default: FALSE > Description: Enables CLKIN divide by two features. > > This input divider is in place to take care of this specific problem: > generating clocks from something a little too high speed. =A0Since the > reference clock will become 150MHz after the divider, you just have to > double back up. > > No external logic is needed. The CLKFX2X Output (the doubled output) is what you need to use with a 150 MHz input provided by the internal divide by 2 (3A, check specs for other Spartan 3 product if this is not a 3A). The Doubled output goes to 300 MHz, even though the input limit is 250 MHz. AustinArticle: 134454
On 11 Aug, 09:52, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > MarkAren wrote: > > Hi All, > > > I have a project that requires a small PLD and have honed in on the > > Altera series. > > > Can someone explain the difference between the EPM7064x and the > > EPM3064x series please. > > > Each shares: same number of CLBs, Icc and Fmax, JTAG. > > > The 7k seems newer, but also about twice the price of the 3k > > (Digikey). > > This was a strange exersise in marketing. IIRC > > The 3000 series was a lower cost target, but just very slightly crippled > from the 7000 series. (ie not quite pin compatible. WHY do that?!) > > I think the 3000 series offers less IO on given device. > > I see the 7000 series has lost link-preference on the Altera website. > > These days, Altera's CPLDs are somewhat trailing edge, with Lattice > 4000ZE being the newest technology (most recently released), followed by > Atmel's ATF15xxBE, and then Xilinx XC2Cxx series. > > Speaking of Altera and CPLD's - whatever became of the touted > Altera MAX III CPLDs ? > > Google finds a 2004 Altera road map that says : > MAX III CPLDs > - Intent: Solve Additional Board Management Issues > - Adjust Density, Power & Cost According to Market Requirements > > Seems the plug was pulled on this ? > > -jg wierd? additional board management issues? A reduction would be in order. 128KB of self refresh single port dram would be nice, at one less chip (and no pin out change!) or 16*16K*16 bit (256KB). A bit more denity? Na only the memory (maybe more UFM) or RAM backed UFM (No extra logic 16 bit parallel, good for conserving design flow). MORE density LOWER power LOWER cost :-) How about ? MAX II looks like it was the right dev kit. Maybe memory should have been integrated UFM RAM MIX, 1270 is quite a lot of LEs.Article: 134455
Zorjak wrote:
> I have 300MHz signal that I have to drive to the
> FPGA clock input. That signal I have to connect to the DCM input and
> from it to generate new 300MHz clock.
If your 300MHz signal can drive an input reliably,
why not make that the clock?
-- Mike Treseler
Article: 134456Jim Granville wrote: (snip, I wrote) >> Putting analog PLL frequency multipliers on each string would be >> interesting, but take a lot of extra circuitry. I don't know >> DLL enough to say, but it might work. I would read up on >> DLL (that is, the digital version of the analog PLL). > Why add more jitter/noise ? In my example, a low 1Mhz timebase > reciprocal counter is 63 TIMES more accurate than the OP's > 15.9mHz spec - so it has 6 extra bits of precision. > (500KHz would be my trade-off target) Yes, I was thinking about running it continuously, or at least close. > On a more practical note, I can't see a stored-cal approach > working very well (too much thermal drifing about..) I agree. -- glenArticle: 134457
On Aug 11, 1:49=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Yes, I was thinking about running it continuously, > or at least close. > > > On a more practical note, I can't see a stored-cal approach > > working very well (too much thermal drifing about..) > > I agree. > > -- glen Making the tuning accuracy too fine is a waste of time. I have found that a string naturally fluctuates in pitch by up to a tenth of a cent or more, even if it is being resonantly sustained. I have also let a string be maintained at a constant PWM for up to three days with no measurable change in pitch. Maintaining the string at a constant temperature is basically the same as an ordinary piano sitting at room temperature. Gradual changes in humidity are by far the largest factor in causing a piano to go out of tune anyway. Don Kansas CityArticle: 134458
eromlignod wrote: > On Aug 11, 1:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > >>Yes, I was thinking about running it continuously, >>or at least close. >> >> >>>On a more practical note, I can't see a stored-cal approach >>>working very well (too much thermal drifing about..) >> >>I agree. >> >>-- glen > > Making the tuning accuracy too fine is a waste of time. Not to an engineer ;) > I have found > that a string naturally fluctuates in pitch by up to a tenth of a cent > or more, even if it is being resonantly sustained. but how do you know if that variation is the resonance changing, or your measurement noise floor ? <paste> > I need an accuracy of > less than one "cent" (1/100th of a musical semitone). One cent sharp > at 27.5 Hz is > 27.5 * (2**(1/1200)) = 27.5159 Hz So that's ~477ppm, and the one tenth you mention is 47ppm - and that has to be close to the noise floor of sense of a single note (14+ bits), (expect rather worse measurement floor on 44 notes all at once!) > I have also let a string be maintained at a constant PWM for up to > three days with no measurable change in pitch. Maintaining the string > at a constant temperature is basically the same as an ordinary piano > sitting at room temperature. Almost : It depends on your total power budget, needed for your thermal expansion tuning. All that 'abnormal' heat is going to spread slowly, and also dry things out - so you will have a lot of time constants in a working system. How many watts does this typically drain, when running ? Coefficent of thermal expansion of the range of strings ? (steel is ~11-13ppm/'C) -jgArticle: 134459
I'm taking gamma-corrected RGB and displaying it on a linear device. If you consider R, G, B in [0,1) then R' = R ** 2.2 and so on. For my first version I just instantiated an 8-bit 'square' megafunction in Quartus, which turns out to be 30 LUTs (possibly less at map time because I'm ignoring the lower 8 bits of the output). Obviously the power of 2 isn't quite a power of 2.2. After testing a RAM-based lookup table to do 2.2, I decided to build the equivalent case statement and see how it worked out. 119 LUTs. The table has many repeated value at the low end and skips some values at the high end. The transition points between runs of values (at the low end) and the exact values (at the high end) could be shifted "slightly" with little quality penalty but possibly space savings. Is there a methodical way to minimize the logic by allowing these slight errors? I can't just 'x' some values because I care about monotonicity. (and yes, I'm aware that my internal color path should probably be wider than my output 8 bits, at which point this may become moot, but I'm still curious) -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 134460
On Aug 11, 4:27=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > > Making the tuning accuracy too fine is a waste of time. > > Not to an engineer ;) I am an engineer with 22 years' experience (UMR 1986). I also studied piano at the UMKC Consevatory of Music for sixteen years, starting in 1972. > > I have found > > that a string naturally fluctuates in pitch by up to a tenth of a cent > > or more, even if it is being resonantly sustained. > > but how do you know if that variation is the resonance changing, or your > measurement noise floor ? Believe me, I have extensively researched pitch and tuning, with help from the Piano Technicians Guild (of which I am a member) and the ME department of the University of Wichita. Counting a 50 MHz clock gives me much more accuracy than is needed. > So that's ~477ppm, and the one tenth you mention is 47ppm - and that has > to be close to the noise floor of sense of a single note (14+ bits), > (expect rather worse measurement floor on 44 notes all at once!) > > > I have also let a string be maintained at a constant PWM for up to > > three days with no measurable change in pitch. =A0Maintaining the strin= g > > at a constant temperature is basically the same as an ordinary piano > > sitting at room temperature. > > Almost : It depends on your total power budget, needed for your thermal > expansion tuning. All that 'abnormal' heat is going to spread slowly, > and also dry things out - so you will have a lot of time constants > in a working system. > > How many watts does this typically drain, when running ? Power consumption is a function of tuning range and how far each string is out of tune. A study was done at the University of Washington where it was proven that a piano varies in pitch cyclically by less than 20 cents (total runout, worst string) throughout each year (it was a 3-1/2-year study). So I am aiming at a tuning range of about 30 cents to start out with. This would take about 750 watts if every single string were the entire 30 cents out of tune (sharp). Don Kansas CityArticle: 134461
On Aug 11, 10:29=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote: > > > can I read from the FIFO and write into it at the same time? when my 2 > > clocks are independent > > Of course you can read and write simultaneously. That's what a FIFO is > there for. Have you ever read any FIFO description? > Peter Alfke I was just wondering... cause I still dont know why I met with fifo_full active when it isntArticle: 134462
"Ben Jackson" <ben@ben.com> wrote in message news:slrnga1e1b.1ep2.ben@saturn.home.ben.com... > I'm taking gamma-corrected RGB and displaying it on a linear device. If > you consider R, G, B in [0,1) then R' = R ** 2.2 and so on. For my first > version I just instantiated an 8-bit 'square' megafunction in Quartus, > which turns out to be 30 LUTs (possibly less at map time because I'm > ignoring the lower 8 bits of the output). Obviously the power of 2 isn't > quite a power of 2.2. Odd why it should take any LUTs at all...or are you targetting something that doesn't have hardware multipliers? > After testing a RAM-based lookup table to do 2.2, > I decided to build the equivalent case statement and see how it worked > out. 119 LUTs. > Doesn't sound like a lookup table got implemented using internal device memory...or are you targetting something that doesn't have internal memory? Let's see, no hardware multipliers, no internal memory...my god man, what are you using, self-assembling carbon nanotube based logic? > The table has many repeated value at the low end and skips some values at > the high end. The transition points between runs of values (at the low > end) and the exact values (at the high end) could be shifted "slightly" > with little quality penalty but possibly space savings. Is there a > methodical way to minimize the logic by allowing these slight errors? I > can't just 'x' some values because I care about monotonicity. > > (and yes, I'm aware that my internal color path should probably be wider > than my output 8 bits, at which point this may become moot, but I'm still > curious) > See the link below for how I did an sRGB->RGB conversion function. Cleaner and easier to validate than a case statement. http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/b2e4be6480069641/e0ef01b07a9c39cd?hl=en&lnk=st&q=RGB+sRGB+conversion+function+Kevin+Jennings#e0ef01b07a9c39cd Once you've got the constants computed, don't forget to put it into a synchronous process otherwise it will get implemented in LUTs rather than internal memory. I'm guessing that's what happened with your case statement lookup table. i.e. Gazouta <= Lookup(Gazinta) when rising_edge(Clock); Kevin JenningsArticle: 134463
On Aug 11, 8:44=A0am, John_H <newsgr...@johnhandwork.com> wrote: > On Aug 11, 7:29=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote: > > > > can I read from the FIFO and write into it at the same time? when my = 2 > > > clocks are independent > > > Of course you can read and write simultaneously. That's what a FIFO is > > there for. Have you ever read any FIFO description? > > Peter Alfke > > Where else can one get information directly from a bona-fide expert on > FIFOs? > Thanks again for being here, Peter.Article: 134464
On Aug 11, 8:44=A0am, John_H <newsgr...@johnhandwork.com> wrote: > Where else can one get information directly from a bona-fide expert on > FIFOs? > Thanks again for being here, Peter. Hi, John. Is this what you had in mind? FIFOs, a tutorial description by Peter Alfke 8-11-2008 A FIFO is a sequential data buffer that is very easy to use: Write a sequence of data words into the FIFO, and read them out in the same sequence. Writing and reading can overlap. There is no explicit addressing. Most practical implementations use a dual-ported memory (RAM), writing into one port, addressed by the write counter, and reading through the other port, addressed by the read counter. This allows the use of two totally independent clocks for write and read. This is often called asynchronous operation, although writing as well as reading are each synchronous operation in their respective clock domain. Most FIFO designs require free-running clocks, where the write or read operation is controlled by the respective clock enable. A typical FIFO has a DATA IN bus, a DATA OUT bus, a free-running write clock with its Enable control, and a free-running read clock with its Enable control. Such a FIFO is very easy to use, since it hides all functional and timing complexity from the user. FLAGS: The FIFO uses an EMPTY flag to signal to the user that no more read operations should be started. At other times the FULL flag can tells the user that no more write operation should be started. Generating these flags requires that the two addressing counters be compared for equality (identity), although they are incremented by two independent clocks. This is a very tricky operation. To avoid uncontrolled asynchronous decoding spikes, the counters usually count in a Gray sequence, where only one bit changes on any increment. And the two clocks can interact and might cause metastable delays. Even more complex is the decoding of Almost Empty and Almost Full conditions, especially when their offset values are programmable. The user is isolated from all these complexities, but must accept certain timing ambiguities. The Full and Empty flags will always go active exactly on-time, to stop further reading or writing, but these flags must of necessity be allowed to take several clock periods to go inactive again. When the first word is being written into an empty FIFO, Empty goes low, and waits for an enabled read clock to present the Data on the DATA OUT bus. There is a special mode of operation, called First Word Fall Through (FWFT), where the first word written into the empty FIFO directly, on its own, appears at the DATA OUT port. The conventional mode can be called Pull, while FWFT can be called Push. The two modes differ only in their response to the first write into an empty FIFO. The preceding described the most demanding case of a high-speed dual- clock (asynchronous) FIFO. In the special case where both clocks are identical (even if individually enabled) the internal decoding is much simpler, and the binary counters and the control can be designed like a synchronous state machine. At low clock rates, the two clocks can be synchronized to each other, or the read and write operations can be time-multiplexed in a single- port memory. Very small FIFOs can be implemented with flip-flops or register arrays, sometimes even with shift registers.Article: 134465
thanks to everyone you help me a lot. I didn't know about this clk_divide_by_2 attribute. I tryed it and I got what I've needed. That was solution. one more time thanks a lot. best regards Zoran On Aug 11, 7:40=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > Zorjak wrote: > > I have 300MHz signal that I have to drive to the > > FPGA clock input. That signal I have to connect to the DCM input and > > from it to generate new 300MHz clock. > > If your 300MHz signal can drive an input reliably, > why not make that the clock? > > =A0 =A0 =A0 =A0 =A0 -- Mike TreselerArticle: 134466
On 8 aug, 23:59, John McCaskill <jhmccask...@gmail.com> wrote: > On Aug 8, 3:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > > > I'm looking for an FPGA (any flavor) development board > > with an SD card socket connected to the FPGA. > > > It must have all the pins connected (not just SPI mode). > > > So FAR I've found the Arrow LPRP. > > Any other suggestions? > > > Thanks > > > Pete > > A project that Antti did is almost what you want:http://www.microdream-1.= com/Pmod-B.html > > It has SD connected, but only in one bit mode. > > When we developed out cards we put a miniSD card slot on the back of > them: > > http://www.fastertechnology.com/extras/pics/p6a/p6a_back_tn.jpg > > For our development, we just soldered a miniSD to SD converter to a > ribbon cable that was crimped to a DIN connector. Then we plugged that > into an Avnet development board. =A0We put a few caps on the power pins, > and series terminated at the miniSD converter. That worked like a > charm, and it was quick and easy as long as you have the stuff to > solder with. The miniSD to SD converter came with the miniSD card. > > We use the miniSD to configure the V4FX, then it boots its software > from it. We use it in both SD and SPI modes. > > Regards, > > John McCaskillwww.FasterTechnology.com Hi John, I am glad that it has not been left un-noticed, as per distribution agreement the product is now also available from german development board distributor http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D66&product= s_id=3D348 I believe all Xilinx development boards with the 6 pin connector sold by Trenz are bundled with the micro-SD board without extra surchage to the price. This reminds me that I have not published yet all my supporting libraries and _IP_cores_ and reference designs that I have developed for SD and microblaze. I still intend todo that, just my days still have only 25 hours ;) Besides that I am developing more FPGA products and accessories, hopefully rolling our first products in september already Antti PS there are some SD mode ip cores out in the wild.. not very rigid thoughArticle: 134467
Hi I need help in completeing an SDIO open source code. http://bknpk.no-ip.biz/SDIO/doc_1.html http://bknpk.no-ip.biz/Article: 134468
i couldn't catch one point: suppose we are to write 4 data each weighting one byte on fifo. when we enable writing on fifo for example, how should we send in the data? when it takes the data and stores: at rising edges of clock? or at rising edges of enable signal? what happens if i enable writing all the time and do not change the data im sending in? will it keep writing the same data until it is full? thanks..Article: 134469
Pete We have a a SDCARD module to go with our Raggedstone1, Broaddown2/4 and Mulldonoch products. It supports all the pins and has a mosfet power switch to allow crude resets. I don't believe it''s listed on our shop or general websites yet but it is in stock and available. We have some updates for the website ongoing and I think these will appear early September with all the new products etc.. Links for the above boards: http://www.enterpoint.co.uk/moelbryn/raggedstone1.html http://www.enterpoint.co.uk/moelbryn/broaddown2.html John Adair Enterpoint Ltd. On Aug 8, 9:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > I'm looking for an FPGA (any flavor) development board > with an SD card socket connected to the FPGA. > > It must have all the pins connected (not just SPI mode). > > So FAR I've found the Arrow LPRP. > Any other suggestions? > > Thanks > > PeteArticle: 134470
On 12 aug, 10:27, Pinhas <bk...@hotmail.com> wrote: > Hi > I need help in completeing an SDIO open source code. > > http://bknpk.no-ip.biz/SDIO/doc_1.htmlhttp://bknpk.no-ip.biz/ what help do you want, need or expect? the SDIO specs are all under NDA and there are also no known opensource SDIO software drivers where to "derive" missing information. Antti From glaser@ict.tuwien.ac.at Tue Aug 12 03:40:45 2008 Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.arch.fpga Subject: Re: RTL Schematic as EDIF From: Johann Glaser <glaser@ict.tuwien.ac.at> In-Reply-To: <3n9o94ps5t0t8oiarac6f0im9g4p91cf7u@4ax.com> References: <1218101383.15335.13.camel@glaser> <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com> <1218113983.15335.25.camel@glaser> <3n9o94ps5t0t8oiarac6f0im9g4p91cf7u@4ax.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1218537644.16588.17.camel@glaser> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Date: Tue, 12 Aug 2008 12:40:45 +0200 Lines: 27 NNTP-Posting-Host: pc53.ict.tuwien.ac.at X-Trace: 1218537510 tunews.univie.ac.at 28520 128.131.80.53 X-Complaints-To: abuse@tuwien.ac.at Xref: prodigy.net comp.arch.fpga:147247 X-Received-Date: Tue, 12 Aug 2008 06:39:21 EDT (nlpi059.nbdc.sbc.com) Hi! > >The HDL netlist is quite nice for me, but unfortunately a bit hard to > >work with. I'd have to implement a complex parser and as well as some > >"small synthesis" algorithms. > > I question how complex the parser would need to be; it only needs to > understand a small subset of full VHDL. Alternatively, there are VHDL > parsers you could possibly use as a starting point, thought I suspect a > simple recursive descent parser would be faster to write than > researching them. You are right. The output of RTL Compiler (a Verilog netlist) is indeed very simple structured code, structural code. It instantiates wires, gates (nand, not, xor, ...), modules and special Cadence-modules (CDN_mux2, CDN_flop, ...). I found that Icarus Verilog can translate this to EDIF nicely. unfortunately its a flat netlist, but besides that, it looks like I found what I was searching for. And if its not ok, I found a Verilog-parser from the IWLS benchmarks. Probably this can be used to transform Verilog to EDIF. Thanks for your hints HansiArticle: 134471
Hi Glen!
> I think you can just restrict what you allow. There is much
> that could be written in verilog that current synthesis tools
> won't allow. (FF's that work on both edges of the clock,
> as an example.) I would say that you should allow all
> forms of wiring, but restrict what can be connected to
> those wires.
Thanks. Please see my post to Brian Drummond.
Bye
Hansi
From glaser@ict.tuwien.ac.at Tue Aug 12 04:43:38 2008
Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!newsfeed-00.mathworks.com!kanaga.switch.ch!switch.ch!newsserver.news.garr.it!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail
Newsgroups: comp.arch.fpga
Subject: Re: RTL Schematic as EDIF
From: Johann Glaser <glaser@ict.tuwien.ac.at>
In-Reply-To: <489C5F10.70600@gmail.com>
References: <1218101383.15335.13.camel@glaser>
<kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com>
<1218113983.15335.25.camel@glaser> <489B1687.4020203@gmail.com>
<1218185634.15335.41.camel@glaser> <489C5F10.70600@gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1218541418.16588.30.camel@glaser>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Date: Tue, 12 Aug 2008 13:43:38 +0200
Lines: 69
NNTP-Posting-Host: pc53.ict.tuwien.ac.at
X-Trace: 1218541283 tunews.univie.ac.at 28520 128.131.80.53
X-Complaints-To: abuse@tuwien.ac.at
Xref: prodigy.net comp.arch.fpga:147249
X-Received-Date: Tue, 12 Aug 2008 07:44:42 EDT (nlpi059.nbdc.sbc.com)
Hi!
> > Some background information to make my intent plausible: In my PhD I'm
> > investigating how to build custom ultra-low-power logic to a SoC, which
> > is still configurable.
>
> By 'build' do you mean layout a custom chip
> with special primitive logic elements
> and electronic wiring,
> or do you mean make a bit image for
> existing or proposed fpga hardware?
My proposal as PhD is to develop one's own tailored FPGA to be put to a
SoC. Therefore my proposal includes
1) define which logic elements and routing resources and configuration
possibilities you need
2) introduce configuration facility
3) technology map, place&route, layout, chip fabrication
4) utilize the reconfigurable circuit to implement the desired function
5) generate a bitstream for it
Very short, very imprecise, and very demanding. To reduce my work I plan
to utilize commercial and academic tools for the individual steps. And
my original question was regarding one of the steps.
> > On a continuum of configurability between
> > fine-grained (e.g. FPGA, CPLD) to coarse-grained (e.g. Cypress PSoC) my
> > plan is to stay in between. Therefore the RTL netlist, i.e. the first
> > synthesis step, is near my planned granularity.
>
> This is where you lose me.
> Granularity of what?
> The logical source text,
> some intermediate logical description,
> or the hardware container that holds the compiled bit image?
The granularity of logic blocks and their configurability. FPGAs allow
to configure every single bit, but also require you to do. To reduce the
chip area and delay the implement high-level functions like multipliers,
block rams, even whole CPUs. I plan to use larger logic blocks with less
arbitrary function, e.g. adders, counters, multi-bit wide logic blocks,
multiplexers, ...
> > VHDL or Verilog are too user-dependent and flexible.
>
> Only if a human creates the code.
>
> A quartus .vho file is machine generated netlist
> of primitive elements that just happens to use
> structural vhdl as a *netlist* format.
> As others have said, this could be translated to edif.
Please see my reply to Brian Drummond for what I've found out in the
meantime.
> Now, if *you* want to specify which logical elements
> synthesis is to use, tools from A and X won't help.
> In that case, you need a library generation package
> from one of the major synthesis vendors.
> Then you can make any kind of netlist you like,
> but you are on your own for simulation or a target device.
I found that the RTL Compiler accepts "Liberty" library description
files. Hopefully I can utilize these for my work.
Bye
Hansi
Article: 134472Peter Alfke wrote: > On Aug 11, 8:44 am, John_H <newsgr...@johnhandwork.com> wrote: > >> Where else can one get information directly from a bona-fide expert on >> FIFOs? >> Thanks again for being here, Peter. > > Hi, John. > Is this what you had in mind? <snip> All I had in mind, honestly, was thanks.Article: 134473
On Aug 12, 1:20=A0am, Jahid <alicahitkos...@gmail.com> wrote: > i couldn't catch one point: suppose we are to write 4 data each > weighting one byte on fifo. when we enable writing on fifo for > example, how should we send in the data? when it takes the data and > stores: at rising edges of clock? or at rising edges of enable signal? > what happens if i enable writing all the time and do not change the > data im sending in? will it keep writing the same data until it is > full? > > thanks.. The answer to your questions is: Yes. Think of the write port as a simple register. It writes data on the rising clock edge (sometimes the edge polarity is programmable) provided the Enable is active at that moment. If you tell it to write the same data multiple times, it will do that, just like any dumb register would do. Peter AlfkeArticle: 134474
Has anyone successfully used SetClbBits() function of HWICAP 1.00a (driver 2.01a) in EDK 10.1 on Virtex-5? I am getting the impression that it doesn't work at all! Cheers,
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