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
On Fri, 25 Jun 2010 15:34:20 +1000, Sylvia Else <sylvia@not.here.invalid> wrote: >On 25/06/2010 3:09 PM, John Larkin wrote: > >> Rob has a better idea, just make a 16-bit SR that generates a >> thermometer code on powerup, namely walk a 1 into it, and have the sr >> output bits un-clear the i/o flops sequentially. The compiler isn't >> smart enough catch onto that, and we don't need to ground a pin. > >The compiler isn't smart enough in its current version. You may be >laying a trap for the future if you use a technique that relies on the >compiler not performing an analysis that it could perform in principle, >but just doesn't at the moment. > >I suppose it doesn't matter if you sure that neither this circuit, nor >any variant of it, will ever be processed by a newer version of the >compiler. > >Sylvia. This design builds under v11 of the Xilinx software, but won't build under v12, the "Spartan 6 optimized" version. So there's apparently no worry that we'll ever compile it under more advanced compilers; they seem to be getting worse, not better. JohnArticle: 148176
On Fri, 25 Jun 2010 08:46:30 +0000 (UTC), Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >In comp.arch.fpga John Larkin ><jjlarkin@highnotlandthistechnologypart.com> wrote: > > >> We have a Spartan6/45 that's talking to 16 separate SPI A/D >> converters. The data we get back is different, but the clock and chip >> select timings are the same. To get the timing right, avoiding routing >> delays, we need our outgoing stuff to be reclocked by i/o cell >> flipflops. > >> So what happens is that we have one state machine running all 16 SPI >> interfaces. We tell the software that we want the adc chip select >> flops in i/o cells. The compiler decides that all are seeing the same >> input signal, so reduces them to one flipflop. Then it concludes that >> that flipflop can't be in an i/o block, and builds it that way. The >> resulting routing delays are deadly. > >> We couldn't find a way to force these 16 flops into IOBs. Really. > >> The fix is to fool the compiler into thinking the flipflop states are >> not the same. Turns out the the synchronous clear inputs to the flops >> are unused in our design. My suggestion was to ground an input pin, >> run that into the serial input of a 16-bit shift register, and route >> the sr taps to the clears of the 16 output flops. The compiler can't >> know that these levels are in fact always low, so has to gen 16 >> different flops. *Then* it allows the flops to be forced into IOBs. > >> Rob has a better idea, just make a 16-bit SR that generates a >> thermometer code on powerup, namely walk a 1 into it, and have the sr >> output bits un-clear the i/o flops sequentially. The compiler isn't >> smart enough catch onto that, and we don't need to ground a pin. > >> It works. > >> Isn't that all perfectly stupid? > >Did you try to attach a >(* KEEP = "TRUE" *) >attribute to the registers in question? > >I had a similar problem with registers meant to get places in an IOB >absorbed by the feeding BRAM My Xilinx guy, a real pro at this sort of thing, tried everything, "keeps" and "forces" and such. He thought my suggestion was disgusting, which it certainly is, but it broke the logjam and let us get on with our lives. The real figure of merit of any fpga is a mimimal value of K = A/R where A is the actual time you spend downloading, installing, patching, and fighting with the tools, and R is a reasonable design/sim/test time for the project. Xilinx's K value increases steadily over time, and is now roughly 4. JohnArticle: 148177
On Jun 25, 8:26=A0am, Philipp Klaus Krause <p...@spth.de> wrote: > Am 25.06.2010 12:31, schrieb John_H: > > > On Jun 25, 1:09 am, John Larkin > > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > >> We couldn't find a way to force these 16 flops into IOBs. Really. > > > In Synplify, this common type of situation is easily handled with the > > "syn_preserve" directive which is different than Synplify's "keep" > > used for wires in my Verilog code. > > Hmm, but is there a portable way to do these things? Something like C's > "volatile"? > > Philipp I haven't done this recently, but in the previous versions of XST I found you had to shut off "equivalent register removal" AND "resource sharing" in the Synthesis properties, and also "equivalent register removal" in the Map properties to fix the issue. I have also used the shift register start-up approach to make the registers non- equivalent, but I didn't need to do that with all the switches set properly. HTH, GaborArticle: 148178
On Fri, 25 Jun 2010 07:54:00 -0700 (PDT), Gabor <gabor@alacron.com> wrote: >On Jun 25, 8:26 am, Philipp Klaus Krause <p...@spth.de> wrote: >> Am 25.06.2010 12:31, schrieb John_H: >> >> > On Jun 25, 1:09 am, John Larkin >> > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >> >> We couldn't find a way to force these 16 flops into IOBs. Really. >> >> > In Synplify, this common type of situation is easily handled with the >> > "syn_preserve" directive which is different than Synplify's "keep" >> > used for wires in my Verilog code. >> >> Hmm, but is there a portable way to do these things? Something like C's >> "volatile"? >> >> Philipp > >I haven't done this recently, but in the previous versions of XST I >found you had to shut off "equivalent register removal" AND "resource >sharing" in the Synthesis properties, and also "equivalent register >removal" in the Map properties to fix the issue. Those setting become global to the design. If you use sensible HDL structures, that explodes the number of CLBs, so the cure is worse than the disease. JohnArticle: 148179
On 06/25/2010 07:00 AM, John Larkin wrote: > On Fri, 25 Jun 2010 08:46:30 +0000 (UTC), Uwe Bonnes > <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > >> In comp.arch.fpga John Larkin >> <jjlarkin@highnotlandthistechnologypart.com> wrote: >> >> >>> We have a Spartan6/45 that's talking to 16 separate SPI A/D >>> converters. The data we get back is different, but the clock and chip >>> select timings are the same. To get the timing right, avoiding routing >>> delays, we need our outgoing stuff to be reclocked by i/o cell >>> flipflops. >> >>> So what happens is that we have one state machine running all 16 SPI >>> interfaces. We tell the software that we want the adc chip select >>> flops in i/o cells. The compiler decides that all are seeing the same >>> input signal, so reduces them to one flipflop. Then it concludes that >>> that flipflop can't be in an i/o block, and builds it that way. The >>> resulting routing delays are deadly. >> >>> We couldn't find a way to force these 16 flops into IOBs. Really. >> >>> The fix is to fool the compiler into thinking the flipflop states are >>> not the same. Turns out the the synchronous clear inputs to the flops >>> are unused in our design. My suggestion was to ground an input pin, >>> run that into the serial input of a 16-bit shift register, and route >>> the sr taps to the clears of the 16 output flops. The compiler can't >>> know that these levels are in fact always low, so has to gen 16 >>> different flops. *Then* it allows the flops to be forced into IOBs. >> >>> Rob has a better idea, just make a 16-bit SR that generates a >>> thermometer code on powerup, namely walk a 1 into it, and have the sr >>> output bits un-clear the i/o flops sequentially. The compiler isn't >>> smart enough catch onto that, and we don't need to ground a pin. >> >>> It works. >> >>> Isn't that all perfectly stupid? >> >> Did you try to attach a >> (* KEEP = "TRUE" *) >> attribute to the registers in question? >> >> I had a similar problem with registers meant to get places in an IOB >> absorbed by the feeding BRAM > > My Xilinx guy, a real pro at this sort of thing, tried everything, > "keeps" and "forces" and such. He thought my suggestion was > disgusting, which it certainly is, but it broke the logjam and let us > get on with our lives. > > The real figure of merit of any fpga is a mimimal value of > > K = A/R > > where A is the actual time you spend downloading, installing, > patching, and fighting with the tools, and R is a reasonable > design/sim/test time for the project. Xilinx's K value increases > steadily over time, and is now roughly 4. Funny, that's my figure of merit for an embedded processor, too! It's much better these days than it was 20 years ago, although I admit that I've managed to shove it way up recently by deciding to build my own open-source tools. But that's for play, not for money, so it's different. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 148180
On Fri, 25 Jun 2010 08:30:04 -0700, Tim Wescott <tim@seemywebsite.now> wrote: >On 06/25/2010 07:00 AM, John Larkin wrote: >> On Fri, 25 Jun 2010 08:46:30 +0000 (UTC), Uwe Bonnes >> <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >> >>> In comp.arch.fpga John Larkin >>> <jjlarkin@highnotlandthistechnologypart.com> wrote: >>> >>> >>>> We have a Spartan6/45 that's talking to 16 separate SPI A/D >>>> converters. The data we get back is different, but the clock and chip >>>> select timings are the same. To get the timing right, avoiding routing >>>> delays, we need our outgoing stuff to be reclocked by i/o cell >>>> flipflops. >>> >>>> So what happens is that we have one state machine running all 16 SPI >>>> interfaces. We tell the software that we want the adc chip select >>>> flops in i/o cells. The compiler decides that all are seeing the same >>>> input signal, so reduces them to one flipflop. Then it concludes that >>>> that flipflop can't be in an i/o block, and builds it that way. The >>>> resulting routing delays are deadly. >>> >>>> We couldn't find a way to force these 16 flops into IOBs. Really. >>> >>>> The fix is to fool the compiler into thinking the flipflop states are >>>> not the same. Turns out the the synchronous clear inputs to the flops >>>> are unused in our design. My suggestion was to ground an input pin, >>>> run that into the serial input of a 16-bit shift register, and route >>>> the sr taps to the clears of the 16 output flops. The compiler can't >>>> know that these levels are in fact always low, so has to gen 16 >>>> different flops. *Then* it allows the flops to be forced into IOBs. >>> >>>> Rob has a better idea, just make a 16-bit SR that generates a >>>> thermometer code on powerup, namely walk a 1 into it, and have the sr >>>> output bits un-clear the i/o flops sequentially. The compiler isn't >>>> smart enough catch onto that, and we don't need to ground a pin. >>> >>>> It works. >>> >>>> Isn't that all perfectly stupid? >>> >>> Did you try to attach a >>> (* KEEP = "TRUE" *) >>> attribute to the registers in question? >>> >>> I had a similar problem with registers meant to get places in an IOB >>> absorbed by the feeding BRAM >> >> My Xilinx guy, a real pro at this sort of thing, tried everything, >> "keeps" and "forces" and such. He thought my suggestion was >> disgusting, which it certainly is, but it broke the logjam and let us >> get on with our lives. >> >> The real figure of merit of any fpga is a mimimal value of >> >> K = A/R >> >> where A is the actual time you spend downloading, installing, >> patching, and fighting with the tools, and R is a reasonable >> design/sim/test time for the project. Xilinx's K value increases >> steadily over time, and is now roughly 4. > >Funny, that's my figure of merit for an embedded processor, too! > >It's much better these days than it was 20 years ago, although I admit >that I've managed to shove it way up recently by deciding to build my >own open-source tools. But that's for play, not for money, so it's >different. I'm still programming embedded stuff in 68K assembly. Dyno mode. The thing is, I finish a typical instrument's firmware in a week or two and have zero problems with the assembly and debug tools. And rarely find a bug in shipped products. I can archive the source *and all the tools* on one floppy. A lot of people nowadays can't even install and run tool chains that they used a few years ago. Sometimes just grunting it out with simple tools is the best way to get something done. A lot of fancy labor-saving, abstraction-for-reuse stuff is actually game-playing and counter-productive. JohnArticle: 148181
I need to do some fast (<5 usec) conversions of binary integer to ASCII string in HDL (NIOS, FPGA, etc) - basically a fast substitute for sprintf(s,"%d",n); Does anyone know if: 1. It's practical to make an effort to do it in HDL or will it be an endless rats hole? 2. Is there an IP vendor that can sell it to me? If neither, can anyone offer any suggestion on which direction to proceed? Thanks, JJS --- news://freenews.netfront.net/ - complaints: news@netfront.net ---Article: 148182
John Speth <johnspeth@yahoo.com> wrote: > I need to do some fast (<5 usec) conversions of binary integer to ASCII > string in HDL (NIOS, FPGA, etc) - basically a fast substitute for > sprintf(s,"%d",n); > Does anyone know if: > 1. It's practical to make an effort to do it in HDL or will it > be an endless rats hole? > 2. Is there an IP vendor that can sell it to me? > If neither, can anyone offer any suggestion on which direction > to proceed? Look for binary_to_bcd.v on opencores. I used it successfull for some design. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 148183
On 06/25/2010 08:55 AM, John Larkin wrote: > On Fri, 25 Jun 2010 08:30:04 -0700, Tim Wescott<tim@seemywebsite.now> > wrote: > >> On 06/25/2010 07:00 AM, John Larkin wrote: >>> On Fri, 25 Jun 2010 08:46:30 +0000 (UTC), Uwe Bonnes >>> <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >>> >>>> In comp.arch.fpga John Larkin >>>> <jjlarkin@highnotlandthistechnologypart.com> wrote: >>>> >>>> >>>>> We have a Spartan6/45 that's talking to 16 separate SPI A/D >>>>> converters. The data we get back is different, but the clock and chip >>>>> select timings are the same. To get the timing right, avoiding routing >>>>> delays, we need our outgoing stuff to be reclocked by i/o cell >>>>> flipflops. >>>> >>>>> So what happens is that we have one state machine running all 16 SPI >>>>> interfaces. We tell the software that we want the adc chip select >>>>> flops in i/o cells. The compiler decides that all are seeing the same >>>>> input signal, so reduces them to one flipflop. Then it concludes that >>>>> that flipflop can't be in an i/o block, and builds it that way. The >>>>> resulting routing delays are deadly. >>>> >>>>> We couldn't find a way to force these 16 flops into IOBs. Really. >>>> >>>>> The fix is to fool the compiler into thinking the flipflop states are >>>>> not the same. Turns out the the synchronous clear inputs to the flops >>>>> are unused in our design. My suggestion was to ground an input pin, >>>>> run that into the serial input of a 16-bit shift register, and route >>>>> the sr taps to the clears of the 16 output flops. The compiler can't >>>>> know that these levels are in fact always low, so has to gen 16 >>>>> different flops. *Then* it allows the flops to be forced into IOBs. >>>> >>>>> Rob has a better idea, just make a 16-bit SR that generates a >>>>> thermometer code on powerup, namely walk a 1 into it, and have the sr >>>>> output bits un-clear the i/o flops sequentially. The compiler isn't >>>>> smart enough catch onto that, and we don't need to ground a pin. >>>> >>>>> It works. >>>> >>>>> Isn't that all perfectly stupid? >>>> >>>> Did you try to attach a >>>> (* KEEP = "TRUE" *) >>>> attribute to the registers in question? >>>> >>>> I had a similar problem with registers meant to get places in an IOB >>>> absorbed by the feeding BRAM >>> >>> My Xilinx guy, a real pro at this sort of thing, tried everything, >>> "keeps" and "forces" and such. He thought my suggestion was >>> disgusting, which it certainly is, but it broke the logjam and let us >>> get on with our lives. >>> >>> The real figure of merit of any fpga is a mimimal value of >>> >>> K = A/R >>> >>> where A is the actual time you spend downloading, installing, >>> patching, and fighting with the tools, and R is a reasonable >>> design/sim/test time for the project. Xilinx's K value increases >>> steadily over time, and is now roughly 4. >> >> Funny, that's my figure of merit for an embedded processor, too! >> >> It's much better these days than it was 20 years ago, although I admit >> that I've managed to shove it way up recently by deciding to build my >> own open-source tools. But that's for play, not for money, so it's >> different. > > I'm still programming embedded stuff in 68K assembly. Dyno mode. The > thing is, I finish a typical instrument's firmware in a week or two > and have zero problems with the assembly and debug tools. And rarely > find a bug in shipped products. I can archive the source *and all the > tools* on one floppy. A lot of people nowadays can't even install and > run tool chains that they used a few years ago. Good for you. > Sometimes just grunting it out with simple tools is the best way to > get something done. A lot of fancy labor-saving, abstraction-for-reuse > stuff is actually game-playing and counter-productive. It can be. It works well when you have a large group and a product line with lots of components that have both similarities and differences. I worked on a product that had over a dozen CAN-enabled processors roped together on a CAN bus. We had a _lot_ of common code that was reused among all the processors. We also had a lot of code that was individual to each processor. Just handing out specifications for the CAN protocol to a dozen developers and telling them "go" would have been a nightmare. Instead we got the CAN stuff going with just two guys, and used it everywhere. Ditto for a bunch of motor control stuff that was used everywhere, as well as some generic ADC-reading infrastructure and other bits and pieces. But I've seen code reuse turn into a disaster in the hands of someone who's not as smart as they think they are. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 148184
> Yet another way Google can make money from spam. > > "We are not evil" - yeah, right. Just a quick comment to the above. Do you have any sense of what it costs to devise, create, maintain and support infrastructures such as Google's? And, if you do, would you really propose that this ought to be offered for free and yet not try to generate revenue in any way? Unless you don't understand the basic business equation I would suspect that upon reflection you might ultimately realize that Google --and lots of other internet companies-- need to make money in order to offer what they offer the world FOR FREE. Just look at something like Google Earth or Google maps. Amazing stuff. Free for you to use. Sure, they monetize whatever they can. And, they should as these are not cheap products to produce (they literally have cars driving every road in the world with cameras to give you street view). Anyhow, my point is that the vilification of a company like Google is grossly unfounded and is probably a knee-jerk reaction rather than a well thought-out position. Try this: Work your tail off for a year -- seven days a week-- to create a great product without pay. They put it on the web for everyone to use for free. Then read a post from a guy who says you are evil for trying to monetize your creation with paid ads and such things. -MartinArticle: 148185
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > > >We have a Spartan6/45 that's talking to 16 separate SPI A/D >converters. The data we get back is different, but the clock and chip >select timings are the same. To get the timing right, avoiding routing >delays, we need our outgoing stuff to be reclocked by i/o cell >flipflops. > >So what happens is that we have one state machine running all 16 SPI >interfaces. We tell the software that we want the adc chip select >flops in i/o cells. The compiler decides that all are seeing the same >input signal, so reduces them to one flipflop. Then it concludes that >that flipflop can't be in an i/o block, and builds it that way. The >resulting routing delays are deadly. > >We couldn't find a way to force these 16 flops into IOBs. Really. Constraints usually help. In that case it should duplicate logic (if this option is on) to meet timing specifications. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 148186
On 25 Jun., 07:09, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > We have a Spartan6/45 that's talking to 16 separate SPI A/D > converters. The data we get back is different, but the clock and chip > select timings are the same. To get the timing right, avoiding routing > delays, we need our outgoing stuff to be reclocked by i/o cell > flipflops. > > So what happens is that we have one state machine running all 16 SPI > interfaces. We tell the software that we want the adc chip select > flops in i/o cells. The compiler decides that all are seeing the same > input signal, so reduces them to one flipflop. Then it concludes that > that flipflop can't be in an i/o block, and builds it that way. The > resulting routing delays are deadly. > > We couldn't find a way to force these 16 flops into IOBs. Really. > you don't happen to use the output of that flop somewhere in the design? you can't directly instantiate an output FF, but you can instantiate a DDR output FF, OFDDRCPE, with C1 tied low it might work. -LasseArticle: 148187
On Jun 24, 10:09=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > We have a Spartan6/45 that's talking to 16 separate SPI A/D > converters. The data we get back is different, but the clock and chip > select timings are the same. To get the timing right, avoiding routing > delays, we need our outgoing stuff to be reclocked by i/o cell > flipflops. > > So what happens is that we have one state machine running all 16 SPI > interfaces. We tell the software that we want the adc chip select > flops in i/o cells. The compiler decides that all are seeing the same > input signal, so reduces them to one flipflop. Then it concludes that > that flipflop can't be in an i/o block, and builds it that way. The > resulting routing delays are deadly. > > We couldn't find a way to force these 16 flops into IOBs. Really. > > The fix is to fool the compiler into thinking the flipflop states are > not the same. Turns out the the synchronous clear inputs to the flops > are unused in our design. My suggestion was to ground an input pin, > run that into the serial input of a 16-bit shift register, and route > the sr taps to the clears of the 16 output flops. The compiler can't > know that these levels are in fact always low, so has to gen 16 > different flops. *Then* it allows the flops to be forced into IOBs. > > Rob has a better idea, just make a 16-bit SR that generates a > thermometer code on powerup, namely walk a 1 into it, and have the sr > output bits un-clear the i/o flops sequentially. The compiler isn't > smart enough catch onto that, and we don't need to ground a pin. > > It works. > > Isn't that all perfectly stupid? > > The Altera folks are coming to make their pitch tomorrow. This story > may amuse them. > > John I understand your pain. <vent> My gripe is that the tool views constraints as "suggestions". I place a CLB, I see the message "resolved that xxx is at yyy", it doesn't meet timing, and viewing the routed chip in PlanAhead reveals that 'xxx' is NOT at 'yyy'. Hello? I wouldn't have created the constraint if it wasn't important! Getting documentation on what the tool actually does with constraints is like pulling teeth from a chicken! I recently worked on a project where the design "just doesn't work" with ISE-11 and ISE-12. Works "just fine" with ISE-10, provided the "luck of the Irish" has the CLBs falling where I constrained them to be placed. Xilinx: I know you keep asking me to open a web case, but I've never gotten anything resolved that way. This is a link to the design that does not work with versions 11 and 12: <http://opencores.org/ project,aemb> I've narrowed the failure to the synthesis of the exception module. Build, map, and par all seem OK (you're welcome). </vent> How did the meeting with Altera go? GaryArticle: 148188
Hello, I am implementing a core from xilinx (FFT) and wanted to know how the feedback shift registers are implemented. The xilinx core manual says that the earlier stages that need large shift registers uses Block RAM and other stages use distributed RAM. Does this mean it used SRL16s? How do the SRL16s show up in the MAP report if they are being used? Do they show up under "Specific Feature utilization" or they are just under the "Slices used as LUT (memory)"? Thank you. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148189
On Jun 25, 2:53=A0pm, "onkars"
<onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu> wrote:
> Hello,
>
> I am implementing a core from xilinx (FFT) and wanted to know how the
> feedback shift registers are implemented.
> The xilinx core manual says that the earlier stages that need large shift
> registers uses Block RAM and other stages use distributed RAM. Does this
> mean it used SRL16s?
>
> How do the SRL16s show up in the MAP report if they are being used? Do th=
ey
> show up under "Specific Feature utilization" or they are just under the
> "Slices used as LUT (memory)"?
>
> Thank you. =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com
SRL16s will be reported in the map report. Here is a snippet from one
of mine:
Total Number of 4 input LUTs: 24,429 out of 50,560 48%
Number used as logic: 21,305
Number used as a route-thru: 1,312
Number used for Dual Port RAMs: 842
(Two LUTs used per Dual Port RAM)
Number used for 32x1 RAMs: 104
(Two LUTs used per 32x1 RAM)
Number used as Shift registers: 866
Regards,
John McCaskill
www.FasterTechnology.com
Article: 148190On Fri, 25 Jun 2010 09:19:06 -0700, "John Speth" <johnspeth@yahoo.com> wrote: >I need to do some fast (<5 usec) conversions of binary integer to ASCII >string in HDL (NIOS, FPGA, etc) - basically a fast substitute for >sprintf(s,"%d",n); > >Does anyone know if: > >1. It's practical to make an effort to do it in HDL or will it be an endless >rats hole? %x would be utterly trivial and damn fast; you'd probably meet 5 ns (not us) in Virtex-5 (10ns in Spartan) provided you hold string "s" in registers. One clock cycle and you're done. %d reduces to bcd decoding, or successive division by 10 (which may be easiest as multiplication by a reciprocal). A reasonable goal would be one digit per clock cycle, so approx 10x slower than the above. Not very difficult. If n is restricted (say, 16 or fewer bits) there will be simpler approaches. >2. Is there an IP vendor that can sell it to me? It's too trivial for any IP vendor though you may find something free on opencores.org. - BrianArticle: 148191
On 06/25/2010 05:55 PM, John Larkin wrote: > > I'm still programming embedded stuff in 68K assembly. Dyno mode. The > thing is, I finish a typical instrument's firmware in a week or two > and have zero problems with the assembly and debug tools. And rarely > find a bug in shipped products.[...] That just confirms what I always say: A software tool is never so reliable as after it has gone obsolete. Jeroen BellemanArticle: 148192
On Fri, 25 Jun 2010 23:59:10 +0200, Jeroen Belleman <jeroen@nospam.please> wrote: >On 06/25/2010 05:55 PM, John Larkin wrote: >> >> I'm still programming embedded stuff in 68K assembly. Dyno mode. The >> thing is, I finish a typical instrument's firmware in a week or two >> and have zero problems with the assembly and debug tools. And rarely >> find a bug in shipped products.[...] > >That just confirms what I always say: A software tool is never >so reliable as after it has gone obsolete. > >Jeroen Belleman That's a simple consequence of software tools getting less reliable every generation. JohnArticle: 148193
I want a simple bitmap font to use in my project. I'm looking into using a 80x25 or 80x24 format. Where can I get a font like this in an easy format to incorporate into my project?Article: 148194
On Jun 26, 1:41=A0pm, Giorgos Tzampanakis <g...@hw.ac.uk> wrote: > I want a simple bitmap font to use in my project. I'm looking > into using a 80x25 or 80x24 format. Where can I get a font like > this in an easy format to incorporate into my project? http://www.lmgtfy.com/?q=3Dfree+bitmap+font KJArticle: 148195
On 6/26/2010 11:41 AM, Giorgos Tzampanakis wrote: > I want a simple bitmap font to use in my project. I'm looking > into using a 80x25 or 80x24 format. Where can I get a font like > this in an easy format to incorporate into my project? Getting a font is easy. Getting code that will move that font onto the display you are using is the hard part. So, is 80x25 the LCD pixel H/V or is that the number of characters on the screen. Are you using an FPGA to move the pixels to the screen or a cpu. So many questions, no answers. hamiltonArticle: 148196
hamilton <hamilton@nothere.com> wrote in news:i05j83$k53$1@news.eternal-september.org: > Getting a font is easy. > > Getting code that will move that font onto the display you > are using is the hard part. > > So, is 80x25 the LCD pixel H/V or is that the number of > characters on the screen. > > Are you using an FPGA to move the pixels to the screen or a > cpu. > > So many questions, no answers. > I'm using a PC monitor. 80x25 is the number of characters on screen. I will use a CPU implemented on the FPGA to show the characters.Article: 148197
Giorgos Tzampanakis <gt67@hw.ac.uk> wrote: > I want a simple bitmap font to use in my project. I'm looking > into using a 80x25 or 80x24 format. Where can I get a font like > this in an easy format to incorporate into my project? What is the screen resolution or, in other words, the size of the character cell. If you want something like we had 30 years ago, find the ROM patterns for the MCM6674 or MCM6675. The data sheet is, for example, available from http://www.datasheetarchive.com, including bit pattens. That is a 128 character, 9x7 with descenders. If you are short on memory store it the MCM6674 way, as 9x7 plus one extra bit (see the triangle in the corner) to lower the character by two rows. Otherwise, store it as 11x7 or, to fit in a normal ROM, 16x8. (It fits nicely in a 2716.) -- glenArticle: 148198
Giorgos Tzampanakis wrote: > I want a simple bitmap font to use in my project. I'm looking > into using a 80x25 or 80x24 format. Where can I get a font like > this in an easy format to incorporate into my project? Some nice fonts are available on this page: http://www.zee-3.com/pickfordbros/archive/bitmapfonts.php I've used one of the fonts as an example for my acceleratec FPGA graphics controller: http://www.frank-buss.de/yagraphcon/index.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 148199
On 6/26/2010 1:26 PM, Giorgos Tzampanakis wrote: > hamilton<hamilton@nothere.com> wrote in > news:i05j83$k53$1@news.eternal-september.org: > >> Getting a font is easy. >> >> Getting code that will move that font onto the display you >> are using is the hard part. >> >> So, is 80x25 the LCD pixel H/V or is that the number of >> characters on the screen. >> >> Are you using an FPGA to move the pixels to the screen or a >> cpu. >> >> So many questions, no answers. >> > > I'm using a PC monitor. 80x25 is the number of characters on > screen. I will use a CPU implemented on the FPGA to show the > characters. So, do you have a design for the VGA output from your FPGA ?? H
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