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
In article <1fednYDifbVWOh_anZ2dnUVZ_gKdnZ2d@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Nico Coesel wrote:
> (snip)
>
> > Besides, if you are going to generate random MAC addresses you may get
> > intermittant errors because fixed MAC addresses are expected. Those
> > kind of errors are the last you want on a network.
>
> Not so much network errors as administration problems. It is harder
> to track down devices with variable MAC addresses.
>
The intent was never to have MAC addresses generated at random *in the
field*, i.e., upon interface initialization. The idea was to generate
them at random in the *manufacturing process*; there would not be
"variable" MAC address for a given device over time. We only wanted to
avoid the OUI administration problem.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
Article: 127776>With "wander" I mean low-frequency jitter: >Use a 500 MHz accumulator clock, then use DDS to generate 100.000 001 >MHz. >There is no way any PLL can completely even out the once-a-second >period change. >I picked an extreme example, but there are many simpler cases. >I was not referring to any instability in the time-base xtal >oscillator. That would be on top. Suppose I had a collection of input clocks I could pick from. How many would I need and/or what frequency pattern would I pick in order to avoid the nasty cases? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 127777
Hal Murray wrote: >> With "wander" I mean low-frequency jitter: >> Use a 500 MHz accumulator clock, then use DDS to generate 100.000 001 >> MHz. > >> There is no way any PLL can completely even out the once-a-second >> period change. > >> I picked an extreme example, but there are many simpler cases. >> I was not referring to any instability in the time-base xtal >> oscillator. That would be on top. > > Suppose I had a collection of input clocks I could pick from. > > How many would I need and/or what frequency pattern would I > pick in order to avoid the nasty cases? It depends on what you think is nasty. What's your PLL loop bandwidth and what's an acceptable level of jitter? What's your desired range of output frequency coverage? Subharmonics - where Fsys is approximately N*Fout - are the worst points. If those were all that you needed, you'd have to make sure you can cover the subharmonics for one Fsys with another crystal's selection far enough from its subharmonics that the combination works. DDS frequencies are effectively a cascade of m/m+1 style dividers where the +0/+1 selection is fed by the downstream dividers which chops up the Fsys/m_ish subharmonic. Each effective divider stage reduces the maximum jitter amplitude by a factor of about m. If you have several dividers, the amplitude of any close-in phase-noise spur will be small. The situations that are close to the highest frequency subharmonics have a first-stage divider with a small m and a second divider with a very large divide factor, supplying the m/m+1 change very rarely such that that 1/m unit interval phase step is followed very dutifully by the cleanup PLL and not filtered out. Two small divider stages can still give you a large enough remaining jitter value that the close-in condition still needs to be covered by another crystal. Now. If you have multiple crystals, the frequency differences will come into play. If you want to choose the crystals so that the "bad" frequency windows don't overlap, the system must be designed so the bad windows *with tolerance* don't overlap. Add to that the complexity that you'd have to use one crystal as a "master" frequency to monitor and adjust the sub-Hz frequency value of the other crystal (to avoid a 12 ppm jump when changing from 1201001 Hz to 1201002 Hz, for instance) and you have an ugly situation. Your requirements will help drive the system. I'd do many things before I went for multiple reference clocks, personally. - John_HArticle: 127778
On 4 Jan., 23:09, "HT-Lab" <han...@ht-lab.com> wrote: > At least you are honest. > > I would suggest you search the web first since there is a lot of stuff > available on-line and then come back with specific questions. I would suggest "+float +vhdl" and take the first hit in google for a careful inspection. bye ThomasArticle: 127779
On Jan 8, 2:22 am, Gabor <ga...@alacron.com> wrote: > On Jan 7, 5:50 am, "MJ Pearson" <mjp...@york.ac.uk> wrote: > > > > > >> Hi, thanks for the replies, > > > >> I thought my PCB might be the problem. I didn't perform any impedance > > >> matching or termination. I'm "tapping-off" the signals between the > > camera > > >> and framegrabber. So i have a straight through connection - camera to > > >> framegrabber and then "tap-off" the LVDS data-signals and clock and > > send > > >> these into the DS90CR288A. This way I can setup and control the camera > > >> using the camera software on PC, and just perform data processing on > > >> FPGA. > > > >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done > > >carefully > > >to avoid signal integrity problems at the receiver. However if your > > >LVAL and DVAL signals look correct, you may have lucked out... > > > >> I wasn't sure I needed to terminate the lines, as this would be > > performed > > >> further up the line - at the framegrabber end. The pixel clock from > > the > > >> camera should be 66MHz (I think), so thought I was on the right lines > > with > > >> a 16ns period. The chip however is the 85Mhz version. Is this a > > maximum? > > >> I'm not sure what the clock output of the chip should be - 85Mhz or > > >> 66MHz!? > > > >Channel-Link receivers have a wide frequency range of about 20 MHz > > >minimum to the specified maximum (66 or 85 MHz). 66 MHz should > > >work fine. > > > >> I can see data on the output of the chip, LVAL and DVAL signals are > > >> correct, not sure about the clock. As I say, the output voltage swing > > is > > >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for > > the > > >> description! The distance between the chip and the connector is about > > >> 10mm. Do i need termination resistors across the differential lines in > > my > > >> case? > > > >You may be OK with the 10mm stubs. Definitely don't terminate them > > >if there is already termination at the framegrabber. Also if you > > >still get a proper picture at the framegrabber, you probably > > >have reasonable signal integrity. With your scope it would be > > >hard to look at this... > > > >I'm going to guess that the clock is correct, too, but that your > > >scope is bandwidth limiting the signal to form the sine wave you > > >see. What is the input bandwidth of your scope and probe? Did > > >you try to implement a simple T flip-flop in the FPGA to see if > > >the clock is getting into the chip OK? > > > >Regards, > > >Gabor > > > Thanks again Gabor.. > > > The system does seem to be working ok. I get the correct image at the > > frame-grabber end, and all the signals do seem to be correct. The scope > > I'm using says 60MHz on it, I guess this the bandwidth - in which I guess > > it will struggle to observe the higher frequency signals?? > > > I implemented a T-flip flop, and got a decent signal at half the input > > frequncy across an LED on the board, so it looks like everything is ok - > > probably just my VHDL letting me down! The LVAL, DVAL signals are working > > as expected aswell - used the LEDs to observe these. > > > Just as an aside - when I increase the precision of the camera's output 8 > > bit to 16 bit, the camera sends the data in two "packets". For one LVAL > > pulse, the are two DVAL pulses. I think this maybe camera specific, but I > > think the data may be being sent low bits (0-7) with the first DVAL pulse, > > followed by high bits with the second. My camera is always is in > > camera-link BASE mode. I've scoped all the data channels from the chip, > > and the higher outputs are not used - apart from RxOut 27. Am I right > > thinking that in base mode the data should be re-created as: > > > Bit(0) - RxOut 0 > > Bit(1) - RxOut 1 > > Bit(2) - RxOut 2 > > Bit(3) - RxOut 3 > > Bit(4) - RxOut 4 > > Bit(5) - RxOut 6 > > Bit(6) - RxOut 27 > > Bit(7) - RxOut 5 > > > Just wondered if anyone else had any experience with 16 bit data in base > > mode? > > > Regards > > > Marc. > > The bit assignments are all in the Camera Link Specification: > > http://www.alacron.com/downloads/vncl98076xz/CameraLinkSPEC.pdf > > Most Camera Link cameras use two 8-bit "ports" A & B to output > 16-bits on each clock. I'm not familiar with any cameras that > use DVAL as a pixel framing signal. Base Camera Link supports > up to 24 bits of data per clock. > > Regards, > Gabor Hi, Gabor is right, As an addendum to his comment, I think that some cameras from "Basler" use DVAL as pixel framing signal. It is used when the user want to output some selected region from CCD of camera. If you are getting two pulses of DVAL, check your camera whether it is operating in single or dual tap mode and what is the region of interest in camera setting. Hope this helps, /MHArticle: 127780
On Jan 6, 9:08 am, Wojciech Zabolotny <w...@ise.pw.edu.pl> wrote: > Hi All, > > I have previously send this message to comp.arch.embedded, but probably it > was "NTG", as it is more associated with the soft CPU on FPGA problem. > Therefore I try once (the last one ;-) ) again in the comp.arch.fpga IMO comp.arch.embedded was the correct place. > So I have two questions: > 1) How to avoid the problem with PIC code? > 2) Is it possible to generate the ROM contents with the standard tool like > mips(el)-linux-gnu-objcopy ? > Or how to fix the convert to work under linux? Building the GNU tools for cross compilation is pretty standard. Steven's reply is good. I have a similar script as part of YAR, building newlib also: http://repo.or.cz/w/yari.git?a=blob;f=xtools/BUILD.sh;h=9497207810b6c96770d9b1aec020bd6c2a720b98;hb=ad51cd2a0822dc3883f290d857bf0693991052c2 Regards, TommyArticle: 127781
On 2008-01-07, Rgr <rgrworking@hotmail.com> wrote:
> Hi.
>
> I would like to hear your opinion on the possibility of implementing a
> processor in a CPLD?
> The functionality does not have to be greater than the old 8051 CPU, but I
> would like the flexibility and the possibility of adding additional logic to
> my design.
>
> Has someone worked on this issue, or have an opinion on how to complete this
> task?
We are actually doing this all the time in a course we are giving here called
Digital project laboratory. The CPLDs we are using are the XC9572 and XC95108.
(They are old, but they operate on 5V which is a huge advantage for us since
we have many other 5V components.)
Our students commonly use two XC95108 for a complete microcoded processor.
One mostly used for microcode and one mostly used for ALU stuff. Some students
use many more CPLDs to implement graphics and audio as well but that is
not so common.
A few students manage to fit a complete RISC-like processor into a single
XC9572.
Some things to keep in mind when designing a processor (or any logic for
that matter for a XC95xx-CPLD:
* Budget your design for the number of macroblocks. One macroblock ==
one flip-flop plus some logic in front of it.
* Avoid complex expressions. You will notice that especially adders can
be very expensive (or constructs that infer an adder like less than
or greater than). An example:
reg [7:0] counter;
always @(posedge clk) begin
counter <= counter + 1;
if((counter > 13) && (counter < 131)) begin
outsignal <= 1;
end else begin
outsignal <= 0;
end
end
// Refactor this as:
always @(posedge clk) begin
counter <= counter + 1;
if(counter == 13) begin
outsignal <= 1;
end
if(counter == 130) begin
outsignal <= 0;
end
end
The later version can sometimes reduce the number of macrocells although
there is no guarantee for it. (If we didn't use 13 and 131 but something
like 63 and 192 instead it is likely that the first version is more
optimal than the second version for example)
* Reuse logic (macrocells) if possible
An example of commonly used logic in a simple (non pipelined) processor:
reg [15:0] pc;
reg [15:0] address_reg;
reg [15:0] external_addr;
// Resets not shown for clarity
always @(posedge clk) begin
if(incpc) pc <= pc + 1;
else if(resetpc) pc <= 0;
else if(jump) pc <= jumpaddr;
end
always @(posedge clk) begin
if(loadaddr) address_reg <= accumulator;
always @* begin
if (fetch) external_addr <= pc;
else external_addr <= address_reg;
end
Assuming address_reg and pc are the same width:
This code will use at least 16 macrocells for pc (actually more
due to the adder), 16 macrocells for address_reg and 16 macrocells
for the MUX in front of external_addr which is going out to the memory.
This code can be changed to something like this:
reg [15:0] reg1;
reg [15:0] reg2;
always @* external_addr <= reg1;
always @(posedge clk) begin
if(swap) begin
reg1 <= reg2;
reg2 <= reg1;
end else begin
if(inc1) reg1 <= reg1 + 1;
if(load2_pc) reg2 <= jumpaddr;
else if(load2_addr) reg2 <= accumulator;
else if(zero2) reg2 <= 0;
end
end
By reorganizing the code as above you will complicate your control
path by quite a lot, but you will save the 16 macrocells caused by
the MUX since reg1 is directly connected to external memory. We also
make sure that we don't complicate the macrocells used in the adder
by putting all other operations into the reg2 macrocells. As a bonus
we get address_reg++ for free...
* Bit serial arithmetics can be good in CPLDs in some situations. As
an example, I have a small hobby project running where I have fitted
an entire digital watch into a single XC9572 (although it requires a
very non-standard clock frequency to work as I didn't have enough space
left to fit a clock divider). The watch can both show time (hours,
minutes and seconds) and be used as a timer (minutes,seconds,tenths).
There is also an alarm which functions on (hours,minutes). These units
can be used independently (i.e., the watch still ticks in the background
if I'm setting the alarm or using the timer and the alarm will work even
though I'm using the timer). (Actually, I haven't wired up any circuit
yet, but it is working in simulation and the design fits into a
XC9572.) The time is presented on a display driven by 9368 7-segment
decoders so my design don't need to worry about decimal to 7-segment
decoders inside my design. (Although depending on this is a bit of
a cheat...)
I'm using bit serial arithmetics in order to fit everything into the
XC9572. I do not believe a more parallel solution would work in this
very constrained space although digit-serial might work as well.
At some point I'm planning to write a small web page to detail this
project, unfortunately I don't have time to describe it in more detail
in this already long post.
It is rare that students do anything of the above though, but this is what
I've learned while supervising students and thinking about (and sometimes
exploring) the limits of the hardware we are using.
/Andreas
Article: 127782Hi Glen, hanks for your reply. I included some comments/questions inline... "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:HPqdnWB43KiErx3anZ2dnUVZ_sejnZ2d@comcast.com... > Symon wrote: >> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >> news:Rr2dnc0taeLINuPanZ2dnUVZ_v-hnZ2d@comcast.com... > >> Do you not think that the trace inductance and magnetic field are >> important? You don't mention them at all in your post. Just thinking >> about the capacitance is not the whole story... > > Inductance that is part of an impedance matched transmission > line doesn't count. And why is that? > The situation at the end, where the trace > crosses the gap is a little complicated. As the current spreads > out in the split plane, it isn't quite a transmission line anymore. > The half plane inductance should be pretty low, but it won't > say it doesn't count. > What about the increased loop area because the current goes around the slot? Does this increase the generation of the magnetic field? Are you only considering the inductance of the plane, or the inductance of the trace also? > > At some point I made the assumption that there was something on > the other side of the split plane to make a good capacitor. > (Another split plane would do. It would work on either side.) > You really lost me there. Sorry. > > Consider a circular parallel plate capacitor fed at the center. > Then consider it as concentric ring capacitors and the radial > inductance of those rings. The inductance per (radial) length > decreases with increasing radius, the capacitance per radial > distance increases with increasing radius. I believe that makes > capacitance win out over inductance for reasonable frequencies. > > -- glen > How does the current get from the centre to these "concentric ring capacitors"? I think it travels out radially, and this current generates a magnetic field. HTH, Symon.Article: 127783
setup: On one of our designs we are using a Xilinx partan3 FPGA (XC3S500E -4 FT(G)256 stepping1) and an spi flash (M25P40-VMN6) to store FPGA code, callibration data, board settings,... Problem description: Random SPI commands on the SPI bus from the FPGA to the flash are logged during a power down of the board. Sometimes a complete SPI write sequense is logged which makes the flash content corrupt. root cause: Power down of the FPGA is not correct accoarding to the spec. The fall time of the power supply is to long. this results in a bad behaviour of the micro Blaze(uB). During power down the pointer of the uB is jumping to a random place in the uB code. From this point the uB executes several actions depending on the fall time of the power supply. It happens that the pointer jumps to the "write_spi_flash" function in the code. solution: The best solution is to make the power off sequense of the FPGA according to the spec. It is possible to place a power monitor on the board but this results in a redesign of the board and we do not prefere to do so. question: Is there somebody who knows another solution that does not require a redesign of the board? thanks!Article: 127784
"KJ" <kkjennings@sbcglobal.net> writes: > Keep in mind though that those limits are most likely vendor dependent. > I've used functions that manipulate reals to initialize constant arrays to > produce lookup tables without any problems with vendor A...using vendor X or > Syn, I'm still generating service requests to fix other deficiencies in > their tool that breeze right through with A. Doesn't help you if you're > commited to vendor X, but if you're not, it might. > Which Syn is that... "plify" or "opsys"? I assume the former, given this is an FPGA newsgroup, but... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 127785
jeroen.claes@gemidis.be pisze: > setup: > On one of our designs we are using a Xilinx partan3 FPGA (XC3S500E -4 > FT(G)256 stepping1) and an spi flash (M25P40-VMN6) to store FPGA code, > callibration data, board settings,... > > Problem description: > Random SPI commands on the SPI bus from the FPGA to the flash are > logged during a power down of the board. Sometimes a complete SPI > write sequense is logged which makes the flash content corrupt. > > root cause: > Power down of the FPGA is not correct accoarding to the spec. The fall > time of the power supply is to long. this results in a bad behaviour > of the micro Blaze(uB). During power down the pointer of the uB is > jumping to a random place in the uB code. From this point the uB > executes several actions depending on the fall time of the power > supply. It happens that the pointer jumps to the "write_spi_flash" > function in the code. > > solution: > The best solution is to make the power off sequense of the FPGA > according to the spec. It is possible to place a power monitor on the > board but this results in a redesign of the board and we do not > prefere to do so. > > question: > Is there somebody who knows another solution that does not require a > redesign of the board? > > thanks! You can provide ( in fpga ) mux on spi lines with lock which can be only one locked or something like that. Is it same flash with configuration ? AdamArticle: 127786
Hi, > I downloaded and tried it. And it seems to work. At least data_ok and > data_ok_lt shines. Good -- "*_lt" is the longterm variant which, once lit, is never reset. If "error_lt" does *not* lite up, everything is fine. > I just had to write a script to download from your Trac system and > rename 'DCM_SP' to DCM. Strange, I remember DCM_SP is the DCM variant one should use in Spartan3E... Can't remember for sure... > Now I'm trying to reverse engineer fml_memtest() so I can use it for > other things. > Is your code BSD licensed? (like NetBSD) I hereby place it under LGPL and will update the source code accordingly soon. I currently do not have the time to dig deeply into the HDL open source licensing issue -- but LGPL seems to fit the bill: you may use the component wherever you like, without beeing forced to publish any of your application... But if you enhance the component itself, you're forced to "give back". j.Article: 127787
Hi, Everyone, I have one question regarding passive serial programing of altera fpga. Can flex 8000 series be programed in the same way as cyclone families. Which programing file is used when fpga is programed .sof or .pof. Is the programing equipment compatible. Thanks for any kind of help ZoranArticle: 127788
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:usl18im00.fsf@trw.com... > "KJ" <kkjennings@sbcglobal.net> writes: > >> Keep in mind though that those limits are most likely vendor dependent. >> I've used functions that manipulate reals to initialize constant arrays >> to >> produce lookup tables without any problems with vendor A...using vendor X >> or >> Syn, I'm still generating service requests to fix other deficiencies in >> their tool that breeze right through with A. Doesn't help you if you're >> commited to vendor X, but if you're not, it might. >> > > Which Syn is that... "plify" or "opsys"? I assume the former, given this > is an FPGA newsgroup, but... > Synplify KJArticle: 127789
Górski Adam pisze: > jeroen.claes@gemidis.be pisze: >> setup: >> On one of our designs we are using a Xilinx partan3 FPGA (XC3S500E -4 >> FT(G)256 stepping1) and an spi flash (M25P40-VMN6) to store FPGA code, >> callibration data, board settings,... >> >> Problem description: >> Random SPI commands on the SPI bus from the FPGA to the flash are >> logged during a power down of the board. Sometimes a complete SPI >> write sequense is logged which makes the flash content corrupt. >> >> root cause: >> Power down of the FPGA is not correct accoarding to the spec. The fall >> time of the power supply is to long. this results in a bad behaviour >> of the micro Blaze(uB). During power down the pointer of the uB is >> jumping to a random place in the uB code. From this point the uB >> executes several actions depending on the fall time of the power >> supply. It happens that the pointer jumps to the "write_spi_flash" >> function in the code. >> >> solution: >> The best solution is to make the power off sequense of the FPGA >> according to the spec. It is possible to place a power monitor on the >> board but this results in a redesign of the board and we do not >> prefere to do so. >> >> question: >> Is there somebody who knows another solution that does not require a >> redesign of the board? >> >> thanks! > > You can provide ( in fpga ) mux on spi lines with lock which can be only > one locked or something like that. > > Is it same flash with configuration ? > > Adam You can also use very slow clock on spi bus. In this case write cycle will be longer than power down cycle AdamArticle: 127790
>Hi, > >Gabor is right, As an addendum to his comment, I think that some >cameras from "Basler" use DVAL as pixel framing signal. It is used >when the user want to output some selected region from CCD of camera. >If you are getting two pulses of DVAL, check your camera whether it is >operating in single or dual tap mode and what is the region of >interest in camera setting. > >Hope this helps, > >/MH > Thanks, My camera operates in 2-taps interleaved mode. It operates as a line scan camera, a single row value for each column of the sensor array is calculated and read out. Therefore I don't think the ROI will come into it, but I'm not sure what the taps refer to or their definition, and haven't had any luck in finding out...?Article: 127791
>Hi, Everyone, I have one question regarding passive serial programing >of altera fpga. > >Can flex 8000 series be programed in the same way as cyclone families. >Which programing file is used when fpga is programed .sof or .pof. Is >the programing equipment compatible. See "Configuring FLEX 8000 Devices": http://www.altera.com/literature/an/an033.pdfArticle: 127792
On Jan 8, 3:04 pm, MikeShepherd...@btinternet.com wrote: > >Hi, Everyone, I have one question regarding passive serial programing > >of altera fpga. > > >Can flex 8000 series be programed in the same way as cyclone families. > >Which programing file is used when fpga is programed .sof or .pof. Is > >the programing equipment compatible. > > See "Configuring FLEX 8000 Devices": > > http://www.altera.com/literature/an/an033.pdf Thank You, Mike best regards ZoranArticle: 127793
Hello, Suppose that I'm sampling an asynchronous signal with a FF, without using any synchronizers before it. This FF will become metastable from time to time with a MTBF depending on the device's parameters, the clock rate and the input signal change rate. Can you please suggest *real life* examples of how this can make me fail in a real design, that is, where the time of recovery for the metastable event is indeed 0. Here are two off the top of my head: 1) The output of this FF can be used directly as the output of the device, causing an intermediate value on the output for some time, which can harm other devices. 2) If such an input is sampled by two different FFs for different purposes, they may end up with different results. Thanks in advance, EliArticle: 127794
On 2008-01-08, jeroen.claes@gemidis.be <jeroen.claes@gemidis.be> wrote: > Power down of the FPGA is not correct accoarding to the spec. The fall > time of the power supply is to long. this results in a bad behaviour > of the micro Blaze(uB). During power down the pointer of the uB is > jumping to a random place in the uB code. Perhaps you could modify the SPI interface along the lines of typical watchdog or EEPROM access registers in microcontrollers. They require a very specific sequence of operations to "unlock" the device (eg to disable the watchdog). Then a random bit of code would be less likely to affect your SPI bus. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127795
On 2008-01-08, Zorjak <Zorjak@gmail.com> wrote: > > Can flex 8000 series be programed in the same way as cyclone families. There are differences. I think FLEX actually has MORE ways to configure, eg parallel. > Which programing file is used when fpga is programed .sof or .pof. Is > the programing equipment compatible. A sof is an "sram object file" and is the actual FPGA bitstream. A pof (programming object file??) is a container for writing flash devices. You can put more than one sof in a pof (as well as other data). You use the sof if you do direct JTAG programming. The 'programming equipment' is typically an Altera byteblaster cable. The byteblaster MV cannot program flash devices (iirc) while the byteblaster II can. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127796
On 2008-01-08, Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: > > * Budget your design for the number of macroblocks. One macroblock == > one flip-flop plus some logic in front of it. Very important. And as you hint later, with only 36-108 flops, you can't make much of a clock divider. If you want to operate at human- visible speeds, give yourself a slow clock. > * Avoid complex expressions. You will notice that especially adders can > be very expensive (or constructs that infer an adder like less than > or greater than). An example: On the other hand, you can use much bigger combinatoral expressions in each macrocell of a CPLD than you can in the LUT of a typical FPGA. My experience is that you can fit a lot more logic and a lot less storage in a CPLD than you might initially expect. > exploring) the limits of the hardware we are using. You could look at my website for such an example. I fit a PCI target in a XC95108. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127797
"Andreas Ehliar" <ehliar-nospam@isy.liu.se> wrote in message news:slrnfo6obf.luh.ehliar-nospam@sabor.isy.liu.se... > On 2008-01-07, Rgr <rgrworking@hotmail.com> wrote: >> Hi. >> >> I would like to hear your opinion on the possibility of implementing a >> processor in a CPLD? >> The functionality does not have to be greater than the old 8051 CPU, but >> I >> would like the flexibility and the possibility of adding additional logic >> to >> my design. >> >> Has someone worked on this issue, or have an opinion on how to complete >> this >> task? > > We are actually doing this all the time in a course we are giving here > called > Digital project laboratory. The CPLDs we are using are the XC9572 and > XC95108. > (They are old, but they operate on 5V which is a huge advantage for us > since > we have many other 5V components.) > > Our students commonly use two XC95108 for a complete microcoded processor. > One mostly used for microcode and one mostly used for ALU stuff. Some > students > use many more CPLDs to implement graphics and audio as well but that is > not so common. > > A few students manage to fit a complete RISC-like processor into a single > XC9572. > > Some things to keep in mind when designing a processor (or any logic for > that matter for a XC95xx-CPLD: > > * Budget your design for the number of macroblocks. One macroblock == > one flip-flop plus some logic in front of it. > > * Avoid complex expressions. You will notice that especially adders can > be very expensive (or constructs that infer an adder like less than > or greater than). An example: > > reg [7:0] counter; > always @(posedge clk) begin > counter <= counter + 1; > if((counter > 13) && (counter < 131)) begin > outsignal <= 1; > end else begin > outsignal <= 0; > end > end > > // Refactor this as: > always @(posedge clk) begin > counter <= counter + 1; > if(counter == 13) begin > outsignal <= 1; > end > if(counter == 130) begin > outsignal <= 0; > end > end > > The later version can sometimes reduce the number of macrocells although > there is no guarantee for it. (If we didn't use 13 and 131 but something > like 63 and 192 instead it is likely that the first version is more > optimal than the second version for example) > > > > * Reuse logic (macrocells) if possible > An example of commonly used logic in a simple (non pipelined) processor: > > reg [15:0] pc; > reg [15:0] address_reg; > reg [15:0] external_addr; > // Resets not shown for clarity > always @(posedge clk) begin > if(incpc) pc <= pc + 1; > else if(resetpc) pc <= 0; > else if(jump) pc <= jumpaddr; > end > > always @(posedge clk) begin > if(loadaddr) address_reg <= accumulator; > > always @* begin > if (fetch) external_addr <= pc; > else external_addr <= address_reg; > end > > Assuming address_reg and pc are the same width: > This code will use at least 16 macrocells for pc (actually more > due to the adder), 16 macrocells for address_reg and 16 macrocells > for the MUX in front of external_addr which is going out to the memory. > This code can be changed to something like this: > > reg [15:0] reg1; > reg [15:0] reg2; > always @* external_addr <= reg1; > > always @(posedge clk) begin > if(swap) begin > reg1 <= reg2; > reg2 <= reg1; > end else begin > if(inc1) reg1 <= reg1 + 1; > if(load2_pc) reg2 <= jumpaddr; > else if(load2_addr) reg2 <= accumulator; > else if(zero2) reg2 <= 0; > end > end > > By reorganizing the code as above you will complicate your control > path by quite a lot, but you will save the 16 macrocells caused by > the MUX since reg1 is directly connected to external memory. We also > make sure that we don't complicate the macrocells used in the adder > by putting all other operations into the reg2 macrocells. As a bonus > we get address_reg++ for free... > > * Bit serial arithmetics can be good in CPLDs in some situations. As > an example, I have a small hobby project running where I have fitted > an entire digital watch into a single XC9572 (although it requires a > very non-standard clock frequency to work as I didn't have enough space > left to fit a clock divider). The watch can both show time (hours, > minutes and seconds) and be used as a timer (minutes,seconds,tenths). > There is also an alarm which functions on (hours,minutes). These units > can be used independently (i.e., the watch still ticks in the background > if I'm setting the alarm or using the timer and the alarm will work even > though I'm using the timer). (Actually, I haven't wired up any circuit > yet, but it is working in simulation and the design fits into a > XC9572.) The time is presented on a display driven by 9368 7-segment > decoders so my design don't need to worry about decimal to 7-segment > decoders inside my design. (Although depending on this is a bit of > a cheat...) > > I'm using bit serial arithmetics in order to fit everything into the > XC9572. I do not believe a more parallel solution would work in this > very constrained space although digit-serial might work as well. > > At some point I'm planning to write a small web page to detail this > project, unfortunately I don't have time to describe it in more detail > in this already long post. > > > It is rare that students do anything of the above though, but this is what > I've learned while supervising students and thinking about (and sometimes > exploring) the limits of the hardware we are using. > > /Andreas Thanks for the tips, there are some nice views among them. And thank you all for the answers - I have searched the web sites and come up with some possible solutions. Best RegardsArticle: 127798
Hi all. I am doing a small Processor implementation (with the performance somewhat like an 8051 CPU), and I am designing for "as low power as possible". I want to use reconfigurable logic as I am interested in the the flexibility and the possibility of adding additional logic to my design. Already with aid of the helpful users of this NG I am looking at three competing products. The Coolrunner II CPLD from Xilinx The MAXII from Altera The IGLOO FPGA from Actel When looking at the specs, IGLOO seems to provide the best scores, however, these come from the manufacturer themselves, so I wondered if somebody has worked with low power designs with the above mentioned devices - and could give me some "real-life" experiences? If Actels figures are correct, I must admit I have never worked with their development tools. How are these in user-friendlyness and quality in comparison with for example the Xilinx product (ISE and EDK). Any experiences? I am looking very much forward to her from you The Best of Regards :-)Article: 127799
"Rgr" <rgrworking@hotmail.com> wrote in message news:47839199$0$15886$edfadb0f@dtext01.news.tele.dk... > Hi all. > I am doing a small Processor implementation (with the performance somewhat > like an 8051 CPU), and I am designing for "as low power as possible". > I want to use reconfigurable logic as I am interested in the the > flexibility and the possibility of adding additional logic to my design. > > Already with aid of the helpful users of this NG I am looking at three > competing products. > The Coolrunner II CPLD from Xilinx > The MAXII from Altera > The IGLOO FPGA from Actel > > When looking at the specs, IGLOO seems to provide the best scores, > however, these come from the manufacturer themselves, so I wondered if > somebody has worked with low power designs with the above mentioned > devices - and could give me some "real-life" experiences? > > If Actels figures are correct, I must admit I have never worked with their > development tools. How are these in user-friendlyness and quality in > comparison with for example the Xilinx product (ISE and EDK). Any > experiences? I can't speak for Libero but Actel Designer (P&R only) is logical and very easy to use. The only downside is that P&R takes ages which might be due to their fine grain architecture. If you are planning to use an Igloo then I would suggest to get their AGL600 prototype board and not the Icicle since the AGL125 might be too small for your processor design. I have just done a quick test with the Oregano 8051 and it takes 5178 Tiles (AGL125 only has 3072) http://www.oregano.at/ip/8051.htm Hans www.ht-lab.com > > I am looking very much forward to her from you > The Best of Regards :-) >
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