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 Mar 27, 1:25=A0pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > On Fri, 27 Mar 2009 08:19:43 -0700 (PDT), John <sampson...@gmail.com> > wrote: > > > > >On Mar 27, 11:04=A0am, rickman <gnu...@gmail.com> wrote: > >> I'm sure I'm not the first person to control an oscillator by the > >> amount of data in a FIFO, but I haven't found a reference to this > >> design which is similar to a PLL. > > >> In place of a typical phase detector, I am using the count of samples > >> in the FIFO to control the DCO which drives the output clock. =A0Data = is > >> clocked into the FIFO using the reference (input) clock. =A0I have an > >> integrator between the data count and the DCO phase step input. =A0The > >> data count is also offset so that it is zero when at the set point. > > >> I am having trouble understanding how to model this design. =A0Is ther= e > >> a unique name for this sort of circuit? =A0At first I was thinking it > >> was a frequency locked loop (FLL), but then I realized that the data > >> count works the same as a phase detector by integrating the difference > >> in frequency of the two signals, it just has a granularity of 1 cycle > >> and does not wrap around like typical phase detectors do. =A0So should= I > >> be using the same model for this as I would use for a conventional PLL > >> using a standard phase detector? > > >> I am having trouble getting the circuit to lock in quickly without > >> overshoot and hold lock as the frequency shifts. =A0I believe I need t= o > >> add a proportional element to the feedback loop. =A0I am also > >> considering using different coefficients when the loop is locked and > >> when not locked. > > >> Am I making this hard and it just needs to be treated like any other > >> PLL? > > >> Rick > > >I call it a "rate-locked loop", but I'm not sure there is an official > >name. Other keywords include "elastic store" or "elastic buffer". > > >You can write loop equations and get response curves. If the buffer > >length is B, the error is (x - B/2)/(B/2) where x is how much is in > >the buffer. The feedback is through a standard lead-lag filter, the > >output of which controls the buffer's empty rate. > > >John > > Also sometimes called a "delay-locked loop". I am pretty sure that this is not a delay locked loop. A DLL uses a delay in the feedback path to generate an output that has a different phase than the original. This is often used to compensate for a delay elsewhere in the clock path. In one incarnation of the design of this circuit the error integrator was enabled by the input clock enable. If there was a phase shift in the input and output clock enables, it would produce a single count of difference during part of the cycle, but would be zero again by the next input clock enable. However, with the phase accumulator (DCO) operating on each cycle of the main clock, this single count would be added in producing what amounted to a fractional phase step compared to the value in the error integrator. The result is that the smallest adjustments in output frequency would be made by the phasing of the input and output signals. However, the phase would never be corrected in the error integrator. This is a bit hard to describe in words. I hope it is clear. RickArticle: 139376
On Mar 27, 12:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On Fri, 27 Mar 2009 08:04:43 -0700 (PDT) > > > > rickman <gnu...@gmail.com> wrote: > > I'm sure I'm not the first person to control an oscillator by the > > amount of data in a FIFO, but I haven't found a reference to this > > design which is similar to a PLL. > > > In place of a typical phase detector, I am using the count of samples > > in the FIFO to control the DCO which drives the output clock. =A0Data i= s > > clocked into the FIFO using the reference (input) clock. =A0I have an > > integrator between the data count and the DCO phase step input. =A0The > > data count is also offset so that it is zero when at the set point. > > > I am having trouble understanding how to model this design. =A0Is there > > a unique name for this sort of circuit? =A0At first I was thinking it > > was a frequency locked loop (FLL), but then I realized that the data > > count works the same as a phase detector by integrating the difference > > in frequency of the two signals, it just has a granularity of 1 cycle > > and does not wrap around like typical phase detectors do. =A0So should = I > > be using the same model for this as I would use for a conventional PLL > > using a standard phase detector? > > > I am having trouble getting the circuit to lock in quickly without > > overshoot and hold lock as the frequency shifts. =A0I believe I need to > > add a proportional element to the feedback loop. =A0I am also > > considering using different coefficients when the loop is locked and > > when not locked. > > > Am I making this hard and it just needs to be treated like any other > > PLL? > > > Rick > > Sure sounds like it's just a phase detector. =A0That said, unless every > clock of the input clock is putting a sample into the FIFO you start > giving away gain pretty rapidly. =A0In a digital feedback loop, > gain=3Dbits=3Dability to treat things as mathematically perfect rather th= an > mucking around in non-linear quantization effects. I'm not sure I understand this. Every clock of the input *does* put a value into the FIFO. Every clock of the output removes a sample from the FIFO. One thing that is confusing me is that I want to update the error integrator only on the input clock enable, but the output clock phase accumulator operates on every cycle of the main clock. So a single count in the error value produces multiple counts of offset in the phase of the output. This seems to make the output rate never stabilize completely. I suspect that I need to provide proper low pass filtering which I don't currently use. RickArticle: 139377
On Mar 27, 7:10=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 27, 12:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > > > > > On Fri, 27 Mar 2009 08:04:43 -0700 (PDT) > > > rickman <gnu...@gmail.com> wrote: > > > I'm sure I'm not the first person to control an oscillator by the > > > amount of data in a FIFO, but I haven't found a reference to this > > > design which is similar to a PLL. > > > > In place of a typical phase detector, I am using the count of samples > > > in the FIFO to control the DCO which drives the output clock. =A0Data= is > > > clocked into the FIFO using the reference (input) clock. =A0I have an > > > integrator between the data count and the DCO phase step input. =A0Th= e > > > data count is also offset so that it is zero when at the set point. > > > > I am having trouble understanding how to model this design. =A0Is the= re > > > a unique name for this sort of circuit? =A0At first I was thinking it > > > was a frequency locked loop (FLL), but then I realized that the data > > > count works the same as a phase detector by integrating the differenc= e > > > in frequency of the two signals, it just has a granularity of 1 cycle > > > and does not wrap around like typical phase detectors do. =A0So shoul= d I > > > be using the same model for this as I would use for a conventional PL= L > > > using a standard phase detector? > > > > I am having trouble getting the circuit to lock in quickly without > > > overshoot and hold lock as the frequency shifts. =A0I believe I need = to > > > add a proportional element to the feedback loop. =A0I am also > > > considering using different coefficients when the loop is locked and > > > when not locked. > > > > Am I making this hard and it just needs to be treated like any other > > > PLL? > > > > Rick > > > Sure sounds like it's just a phase detector. =A0That said, unless every > > clock of the input clock is putting a sample into the FIFO you start > > giving away gain pretty rapidly. =A0In a digital feedback loop, > > gain=3Dbits=3Dability to treat things as mathematically perfect rather = than > > mucking around in non-linear quantization effects. > > I'm not sure I understand this. =A0Every clock of the input *does* put a > value into the FIFO. =A0Every clock of the output removes a sample from > the FIFO. > > One thing that is confusing me is that I want to update the error > integrator only on the input clock enable, but the output clock phase > accumulator operates on every cycle of the main clock. =A0So a single > count in the error value produces multiple counts of offset in the > phase of the output. =A0This seems to make the output rate never > stabilize completely. =A0I suspect that I need to provide proper low > pass filtering which I don't currently use. > > Rick Here's a simulation in Matlab that shows output rate adaptation to keep buffer half full. John nco_fill=3D1; nco_empty=3D1; % write rate is 1/3 phinc_fill=3D1/3; % read rate offset from write rate by 'ppm' ppm=3D100; phinc_empty=3Dphinc_fill*(1+ppm/1e6); pherr=3D0; Ki=3D1/1000; Kp=3D1/10; acc=3D0; N=3D1e5; backlog=3D0; bv =3D zeros(N,1);sv=3Dbv;nf=3Dbv;ne=3Dbv;ev=3Dbv; % buffer size is B B=3D1000; state=3D0; for k =3D 1:N if(nco_fill-phinc_fill<=3D0) % write a sample into buffer when fill nco wraps backlog =3D backlog + 1; nco_fill =3D 1-abs(nco_fill-phinc_fill); else nco_fill=3Dnco_fill-phinc_fill; end if(state =3D=3D 0) % state 0: waiting for half full condition if(backlog > B/2) state =3D 1; end elseif(state =3D=3D 1) % state 1: emptying nco_empty=3Dnco_empty-phinc_empty-pherr; if(nco_empty<=3D0) % read a sample from buffer when empty nco wraps backlog =3D backlog-1; nco_empty=3D1-abs(nco_empty-phinc_empty-pherr); end % compute error and apply to PI filter e =3D (backlog-B/2)/(B/2); acc =3D Kp*e + acc; lag =3D Ki*acc; lead =3D Kp*e; pherr =3D lag + lead; end bv(k) =3D backlog; end plot(bv);grid;shg;title('Backlog');Article: 139378
For some time I've found it pretty humorous that Xilinx boast of "True LUT6" in all their Virtex 5+ marketing material. Do they really think that they can somehow imply that Altera's ALM isn't a "True LUT6" when in fact it's obvious that the ALM encompasses a LUT6 and much more. Or are there some unreal LUT6 out there? TommyArticle: 139379
On Mar 27, 3:25=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > and i was considering MIPS if allowing more resource hungry > implementations Hey Antti, I would be delighted if you would help lower the resource requirement of YARI to suit your needs :-) I sure would learn a lot in the process. TommyArticle: 139380
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:ca64ba48-4e07-42eb-b0c2-28d6ce8def81@d19g2000prh.googlegroups.com... > For some time I've found it pretty humorous that Xilinx boast of "True > LUT6" in all their Virtex 5+ marketing material. Do they really think > that they can somehow imply that Altera's ALM isn't a "True LUT6" when > in fact it's obvious that the ALM encompasses a LUT6 and much more. > > Or are there some unreal LUT6 out there? > > Tommy Ooh! Ooh! , Tommy! Thank the Lord you posted. We would never have grasped that corporations do marketing! Do NVidia do crappy advertising also? Lots of love, Syms.Article: 139381
On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: >> On Fri, 27 Mar 2009 08:19:43 -0700 (PDT), John <sampson...@gmail.com> >> wrote: >> >> >> >> >On Mar 27, 11:04 am, rickman <gnu...@gmail.com> wrote: >> >> I'm sure I'm not the first person to control an oscillator by the >> >> amount of data in a FIFO, but I haven't found a reference to this >> >> design which is similar to a PLL. >> >> >> In place of a typical phase detector, I am using the count of samples >> >> in the FIFO to control the DCO which drives the output clock. Data is >> >> clocked into the FIFO using the reference (input) clock. I have an >> >> integrator between the data count and the DCO phase step input. The >> >> data count is also offset so that it is zero when at the set point. >> >> >> I am having trouble understanding how to model this design. Is there >> >> a unique name for this sort of circuit? At first I was thinking it >> >> was a frequency locked loop (FLL), but then I realized that the data >> >> count works the same as a phase detector by integrating the difference >> >> in frequency of the two signals, it just has a granularity of 1 cycle >> >> and does not wrap around like typical phase detectors do. So should I >> >> be using the same model for this as I would use for a conventional PLL >> >> using a standard phase detector? >> >> >> I am having trouble getting the circuit to lock in quickly without >> >> overshoot and hold lock as the frequency shifts. I believe I need to >> >> add a proportional element to the feedback loop. I am also >> >> considering using different coefficients when the loop is locked and >> >> when not locked. >> >> >> Am I making this hard and it just needs to be treated like any other >> >> PLL? >> >> >> Rick >> >> >I call it a "rate-locked loop", but I'm not sure there is an official >> >name. Other keywords include "elastic store" or "elastic buffer". >> >> >You can write loop equations and get response curves. If the buffer >> >length is B, the error is (x - B/2)/(B/2) where x is how much is in >> >the buffer. The feedback is through a standard lead-lag filter, the >> >output of which controls the buffer's empty rate. >> >> >John >> >> Also sometimes called a "delay-locked loop". > >I am pretty sure that this is not a delay locked loop. A DLL uses a >delay in the feedback path to generate an output that has a different >phase than the original. This is often used to compensate for a delay >elsewhere in the clock path. > >In one incarnation of the design of this circuit the error integrator >was enabled by the input clock enable. If there was a phase shift in >the input and output clock enables, it would produce a single count of >difference during part of the cycle, but would be zero again by the >next input clock enable. However, with the phase accumulator (DCO) >operating on each cycle of the main clock, this single count would be >added in producing what amounted to a fractional phase step compared >to the value in the error integrator. The result is that the smallest >adjustments in output frequency would be made by the phasing of the >input and output signals. However, the phase would never be corrected >in the error integrator. > >This is a bit hard to describe in words. I hope it is clear. > >Rick That's also a DLL, and perhaps the more commonly-used meaning of the term in my experience. This FIFO thing is also pretty common but doesn't seem to have a universal name. As John mentioned, they've been referred to as RLLs, "Elastic buffer", and I've heard DLL when the purpose was to match the delay to some other output to which the stream needs to be synchronized. In the satellite world there's also "plesiochronous buffer" (one of my fave names for this). I guess since the jobs that it does can different a universal name is impractical. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.phpArticle: 139382
On Fri, 27 Mar 2009 08:04:43 -0700, rickman wrote: > I'm sure I'm not the first person to control an oscillator by the amount > of data in a FIFO, but I haven't found a reference to this design which > is similar to a PLL. > > In place of a typical phase detector, I am using the count of samples in > the FIFO to control the DCO which drives the output clock. Data is > clocked into the FIFO using the reference (input) clock. I have an > integrator between the data count and the DCO phase step input. The > data count is also offset so that it is zero when at the set point. > > I am having trouble understanding how to model this design. Is there a > unique name for this sort of circuit? I don't believe so, but I'm not good with names. > At first I was thinking it was a > frequency locked loop (FLL), but then I realized that the data count > works the same as a phase detector by integrating the difference in > frequency of the two signals, it just has a granularity of 1 cycle and > does not wrap around like typical phase detectors do. So should I be > using the same model for this as I would use for a conventional PLL > using a standard phase detector? Yes and no. It doesn't wrap, but it does quantize. So you still need to model the offset accumulation process as an integration, but you don't need to model the phase accumulator rollover, and you do need to model quantization one way or another. > I am having trouble getting the circuit to lock in quickly without > overshoot and hold lock as the frequency shifts. I believe I need to > add a proportional element to the feedback loop. You sure do! How well does a double integrator loop with no damping settle, after all? > I am also considering > using different coefficients when the loop is locked and when not > locked. That may be wise. > Am I making this hard and it just needs to be treated like any other > PLL? > > Rick I think you're overanalyzing some simple things, and overlooking some complexities. You should be able to _leverage_ your knowledge of PLL theory, but you have to modify it wisely to make it work in this case. -- http://www.wescottdesign.comArticle: 139383
On Fri, 27 Mar 2009 16:10:07 -0700, rickman wrote: > > > I'm sure I'm not the first person to control an oscillator by the > > > amount of data in a FIFO, but I haven't found a reference to this > > > design which is similar to a PLL. > > > > In place of a typical phase detector, I am using the count of samples > > > in the FIFO to control the DCO which drives the output clock. Â Data is > > > clocked into the FIFO using the reference (input) clock. Â I have an > > > integrator between the data count and the DCO phase step input. Â The > > > data count is also offset so that it is zero when at the set point. > > > > I am having trouble understanding how to model this design. Â Is there > > > a unique name for this sort of circuit? Â At first I was thinking it > > > was a frequency locked loop (FLL), but then I realized that the data > > > count works the same as a phase detector by integrating the difference > > > in frequency of the two signals, it just has a granularity of 1 cycle > > > and does not wrap around like typical phase detectors do. Â So should I > > > be using the same model for this as I would use for a conventional PLL > > > using a standard phase detector? > > > > I am having trouble getting the circuit to lock in quickly without > > > overshoot and hold lock as the frequency shifts. Â I believe I need to > > > add a proportional element to the feedback loop. Â I am also > > > considering using different coefficients when the loop is locked and > > > when not locked. > > > > Am I making this hard and it just needs to be treated like any other > > > PLL? > > > > Rick > > > Sure sounds like it's just a phase detector. Â That said, unless every > > clock of the input clock is putting a sample into the FIFO you start > > giving away gain pretty rapidly. Â In a digital feedback loop, > > gain=bits=ability to treat things as mathematically perfect rather than > > mucking around in non-linear quantization effects. > > I'm not sure I understand this. Â Every clock of the input *does* put a > value into the FIFO. Â Every clock of the output removes a sample from > the FIFO. > > One thing that is confusing me is that I want to update the error > integrator only on the input clock enable, but the output clock phase > accumulator operates on every cycle of the main clock. Â So a single > count in the error value produces multiple counts of offset in the > phase of the output. Â This seems to make the output rate never > stabilize completely. Â I suspect that I need to provide proper low > pass filtering which I don't currently use. > > Rick Perhaps you need to crank your integrator gain down? -- http://www.wescottdesign.comArticle: 139384
On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > sorry, i did mean vendor provided open-source one (the onlysuch one > bein mico32) I'm still lost as to why you exclude those ? If it is open source, you are free to start your own branch design, should you spot something that really need adding, but can only be done at the cost of something else.... > and as of clean room microblaze vs i8080 clone, i think i did think > i8080 clone is more safe and clean then microblaze clones Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature of FPGAs makes register based cores more natural. (indeed, even ones with a register frame pointer) What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ? -jgArticle: 139385
On Fri, 27 Mar 2009 08:04:43 -0700, rickman wrote: > I'm sure I'm not the first person to control an oscillator by the amount > of data in a FIFO, but I haven't found a reference to this design which > is similar to a PLL. > > In place of a typical phase detector, I am using the count of samples in > the FIFO to control the DCO which drives the output clock. Data is > clocked into the FIFO using the reference (input) clock. I have an > integrator between the data count and the DCO phase step input. The > data count is also offset so that it is zero when at the set point. > > I am having trouble understanding how to model this design. Is there a > unique name for this sort of circuit? At first I was thinking it was a > frequency locked loop (FLL), but then I realized that the data count > works the same as a phase detector by integrating the difference in > frequency of the two signals, it just has a granularity of 1 cycle and > does not wrap around like typical phase detectors do. So should I be > using the same model for this as I would use for a conventional PLL > using a standard phase detector? > > I am having trouble getting the circuit to lock in quickly without > overshoot and hold lock as the frequency shifts. I believe I need to > add a proportional element to the feedback loop. I am also considering > using different coefficients when the loop is locked and when not > locked. > > Am I making this hard and it just needs to be treated like any other > PLL? Hi Rick, I've done this sort of thing in a few real-world designs. The FIFO is a phase / frequency detector when used this way, and the regular PLL theory applies. I break the PFD implementations into a number of types: 1. The "half full" output of the FIFO is used as the phase error signal. This gives bang-bang control, which can result in a chaotic system. These are hard to analyse, but can still be made to give good results. Things like jitter gain will vary with input jitter amplitude. (This doesn't apply to your design, and I won't consider it further.) 2a. The depth output of the FIFO is used to give a (more or less) linear phase error signal. The FIFO will have stops at either end (writes disabled if full and reads disabled if empty) which means that the FIFO also acts as a frequency detector (e.g. if there is a constant difference in the input and output frequencies, the phase error signal will have an average value that is non-zero). Note that the frequency detector doesn't work in a linear way: it is either +max, -max, or off (and the FIFO is operating as a phase detector with a linear output). 2b. Like 2a, but without the stops. This disables the frequency detector action of the FIFO. You will need some other sort of frequency detector to enable the loop to lock. This can be handy if you want to avoid windup. > So should I be > using the same model for this as I would use for a conventional PLL > using a standard phase detector? Yes. For both 2a and 2b, you can calculate the equivalent phase detector gain in terms of output units per radian of phase error. Analog phase detectors have a gain usually measured in volt / radian or amp / radian (for charge pump types). If you wish, you can convert units to volts to enable you to plug your design into old-fashioned PLL design equations. > I am having trouble getting the circuit to lock in quickly without > overshoot and hold lock as the frequency shifts. I believe I need to > add a proportional element to the feedback loop. Yes, in a Type II system you *need* a zero (from the proportional element) to position the closed loop poles in a good location. (BTW, the Type II system has two (open loop) integrators: one is the integrator in your loop filter, the other is the DCO.) > I am also considering > using different coefficients when the loop is locked and when not > locked. When used as a frequency detector, the FIFO depth output will be stuck at +max or -max as long as the frequency difference is present. You can vary the relative frequency detector / phase detector gain by varying the depth of your FIFO. A deeper FIFO means that +max and -max will be larger, and they will slew your integrator faster (meaning lock time will be lower). It is also possible to go the other way and reduce the effective frequency detector "gain" by clipping the PFD output to smaller limits. When locked, the PFD output only needs to be linear over a limited range, given by the amount of jitter you need to absorb outside the loop bandwidth. This is typically small (perhaps a few cycles?). Clipping the PFD output so that it can't go outside this range can help to reduce windup effects and improve the overshoot during initial frequency acquisition, at the cost of increased lock time. Regards, AllanArticle: 139386
On Mar 28, 12:55=A0am, thomas.sch...@hotmail.fr wrote: > Does anyone know where I could find a xc6200 fpga? I would like to > experiment things on reconfigurable computing and it seems to be the > only fpga with a complete documentation to be fully dynamically > reconfigurable. > Thanks. > > Thomas Atmel AT40 and AT94K also have full documentation :) and are easier to access AnttiArticle: 139387
On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > sorry, i did mean vendor provided open-source one (the onlysuch one > > bein mico32) > > I'm still lost as to why you exclude those ? If it is open source, you > are > free to start your own branch design, should you spot something that > really need adding, but can only be done at the cost of something > else.... > > > and as of clean room microblaze vs i8080 clone, i think i did think > > i8080 clone =A0is more safe and clean then microblaze clones > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature > of FPGAs > makes register based cores more natural. > (indeed, even ones with a register frame pointer) > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ? > > -jg Hi Jim, let me explain in more detail: if I use LatticeMico32 for commercial product targetting Xilinx, Altera.. or if I use MicroBlaze(tm) clone on Altera, Lattice then I suppose it may get unwanted attention, or if not it will get absolute nil support from the vendors where soft-core marketed by direct competitor is used. regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice, et others would not mind, as Intel is not FPGA vendor. and i do not think intel would send C&D either this was the full reasoning behind the selection based on licensing and clones. =3D=3D C- Compiler for PicoBlaze, well it can be used for some test to prove it generates code, but PicoBlaze is so crippled that the solution is not much useable. Just too small code space. =3D=3D YARI, hm i am interested too, if even the caches could be disabled it maybe small enough AnttiArticle: 139388
On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > > > > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com" > > > <Antti.Luk...@googlemail.com> wrote: > > > sorry, i did mean vendor provided open-source one (the onlysuch one > > > bein mico32) > > > I'm still lost as to why you exclude those ? If it is open source, you > > are > > free to start your own branch design, should you spot something that > > really need adding, but can only be done at the cost of something > > else.... > > > > and as of clean room microblaze vs i8080 clone, i think i did think > > > i8080 clone =A0is more safe and clean then microblaze clones > > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature > > of FPGAs > > makes register based cores more natural. > > (indeed, even ones with a register frame pointer) > > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ? > > > -jg > > Hi Jim, > > let me explain in more detail: > > if I use LatticeMico32 for commercial product targetting Xilinx, > Altera.. > or > if I use MicroBlaze(tm) clone on Altera, Lattice > > then I suppose it may get unwanted attention, or if not it will get > absolute nil support from the vendors where soft-core marketed > by direct competitor is used. What sort of unwanted attention ? It is open sourced, they do not care if it goes into an ASIC, or any FPGA. As for support, yes, if Z or A tools barf on some detail, then you need to work yourself, but the same applies to any other candidate on your list too.... > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice, > et others > would not mind, as Intel is not FPGA vendor. > and i do not think intel would send C&D either ;) IF you could even find anyone at intel who knew what an 8080 was !! > > C- Compiler for PicoBlaze, well it can be used for some test to prove > it generates code, but PicoBlaze is so crippled that the solution is > not much useable. Just too small code space. But there are choices, and V3 supports 24 bits of address space, which is more than I recall a 8080 offering > > =3D=3D > YARI, hm i am interested too, if even the caches could be disabled > it maybe small enough -jgArticle: 139389
On Mar 28, 8:02=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com" > > > > <Antti.Luk...@googlemail.com> wrote: > > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > > > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com" > > > > <Antti.Luk...@googlemail.com> wrote: > > > > sorry, i did mean vendor provided open-source one (the onlysuch one > > > > bein mico32) > > > > I'm still lost as to why you exclude those ? If it is open source, yo= u > > > are > > > free to start your own branch design, should you spot something that > > > really need adding, but can only be done at the cost of something > > > else.... > > > > > and as of clean room microblaze vs i8080 clone, i think i did think > > > > i8080 clone =A0is more safe and clean then microblaze clones > > > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram nature > > > of FPGAs > > > makes register based cores more natural. > > > (indeed, even ones with a register frame pointer) > > > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc ? > > > > -jg > > > Hi Jim, > > > let me explain in more detail: > > > if I use LatticeMico32 for commercial product targetting Xilinx, > > Altera.. > > or > > if I use MicroBlaze(tm) clone on Altera, Lattice > > > then I suppose it may get unwanted attention, or if not it will get > > absolute nil support from the vendors where soft-core marketed > > by direct competitor is used. > > What sort of unwanted attention ? It is open sourced, they do not care > if > it goes into an ASIC, or any FPGA. > As for support, yes, if Z or A tools barf on some detail, then you > need to work > yourself, but the same applies to any other candidate on your list > too.... > > > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice, > > et others > > would not mind, as Intel is not FPGA vendor. > > and i do not think intel would send C&D either > > ;) IF you could even find anyone at intel who knew what an 8080 was !! > > > > > C- Compiler for PicoBlaze, well it can be used for some test to prove > > it generates code, but PicoBlaze is so crippled that the solution is > > not much useable. Just too small code space. > > But there are choices, and V3 supports 24 bits of address space, which > is more than I recall a 8080 offering > > > > > =3D=3D > > YARI, hm i am interested too, if even the caches could be disabled > > it maybe small enough > > -jg Jim LatticeMico8 Ver 3 supports 24 bit banked address space for the IO but still only 4K instruction memory, and PicoBlaze asfaik doesnt support large memory addressing nativly and, I am not saying my list is good one, or has the right candidates it was the best to my knowledge at the time or making it based on the criteria i had in mind. maybe there are much better candidates thats why i posted in the first place. i8080 is on the list mainly because the lightweigt8080 is rather small.. i was suprised. the goal is to find best CPU for minimal SoC that should be possible to fit to widest possible selection of FPGA's thats why the huge ones are not listed. L8080 fits into smaller end of FPGAs where 32 bit Cores do no longer fit. Also some smaller FPGAs may have too small BRAM so the 32 bit CPUs would just have too small instruction memory for the C compiler to be useable at all. So I would prefer to have some 8 bit CPU on my offering as well. It seems that L8080 could be the candidate. AnttiArticle: 139390
On Mar 28, 6:24=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 28, 8:02=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > > > > > On Mar 28, 5:45=A0pm, "Antti.Luk...@googlemail.com" > > > <Antti.Luk...@googlemail.com> wrote: > > > On Mar 28, 4:53=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > > > > > On Mar 28, 10:25=A0am, "Antti.Luk...@googlemail.com" > > > > > <Antti.Luk...@googlemail.com> wrote: > > > > > sorry, i did mean vendor provided open-source one (the onlysuch o= ne > > > > > bein mico32) > > > > > I'm still lost as to why you exclude those ? If it is open source, = you > > > > are > > > > free to start your own branch design, should you spot something tha= t > > > > really need adding, but can only be done at the cost of something > > > > else.... > > > > > > and as of clean room microblaze vs i8080 clone, i think i did thi= nk > > > > > i8080 clone =A0is more safe and clean then microblaze clones > > > > > Yes, but a 8080 is a lousy 'fit' in a FPGA. The Dual-port ram natur= e > > > > of FPGAs > > > > makes register based cores more natural. > > > > (indeed, even ones with a register frame pointer) > > > > > What is the status of a compiler for Mico8/PicoBlaze/PacoBlaze etc = ? > > > > > -jg > > > > Hi Jim, > > > > let me explain in more detail: > > > > if I use LatticeMico32 for commercial product targetting Xilinx, > > > Altera.. > > > or > > > if I use MicroBlaze(tm) clone on Altera, Lattice > > > > then I suppose it may get unwanted attention, or if not it will get > > > absolute nil support from the vendors where soft-core marketed > > > by direct competitor is used. > > > What sort of unwanted attention ? It is open sourced, they do not care > > if > > it goes into an ASIC, or any FPGA. > > As for support, yes, if Z or A tools barf on some detail, then you > > need to work > > yourself, but the same applies to any other candidate on your list > > too.... > > > > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice= , > > > et others > > > would not mind, as Intel is not FPGA vendor. > > > and i do not think intel would send C&D either > > > ;) IF you could even find anyone at intel who knew what an 8080 was !! > > > > C- Compiler for PicoBlaze, well it can be used for some test to prove > > > it generates code, but PicoBlaze is so crippled that the solution is > > > not much useable. Just too small code space. > > > But there are choices, and V3 supports 24 bits of address space, which > > is more than I recall a 8080 offering > > > > =3D=3D > > > YARI, hm i am interested too, if even the caches could be disabled > > > it maybe small enough > > > -jg > > Jim > > LatticeMico8 Ver 3 supports 24 bit banked address space for the IO > but still only 4K instruction memory, and PicoBlaze asfaik doesnt > support large memory addressing nativly Oops, I just glanced at the data.... - Still, that's not hard to fix. I think the Mico8 does not map the PC onto register-space ? - doing that would allow 16 bit calls ? -jgArticle: 139391
On Mar 27, 10:34 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnu...@gmail.com> > wrote: > > >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > > >> Also sometimes called a "delay-locked loop". > > >I am pretty sure that this is not a delay locked loop. A DLL uses a > >delay in the feedback path to generate an output that has a different > >phase than the original. This is often used to compensate for a delay > >elsewhere in the clock path. > > >In one incarnation of the design of this circuit the error integrator > >was enabled by the input clock enable. If there was a phase shift in > >the input and output clock enables, it would produce a single count of > >difference during part of the cycle, but would be zero again by the > >next input clock enable. However, with the phase accumulator (DCO) > >operating on each cycle of the main clock, this single count would be > >added in producing what amounted to a fractional phase step compared > >to the value in the error integrator. The result is that the smallest > >adjustments in output frequency would be made by the phasing of the > >input and output signals. However, the phase would never be corrected > >in the error integrator. > > >This is a bit hard to describe in words. I hope it is clear. > > >Rick > > That's also a DLL, and perhaps the more commonly-used meaning of the > term in my experience. Yeah, I guess people use whatever term they want often and that makes it hard to communicate about these things. I am pretty sure that the "correct" definition of a Delay Locked Loop is as I described above. But if there is no "official" group to decide these things, there really is no correct definition. > This FIFO thing is also pretty common but doesn't seem to have a > universal name. As John mentioned, they've been referred to as RLLs, > "Elastic buffer", and I've heard DLL when the purpose was to match the > delay to some other output to which the stream needs to be > synchronized. In the satellite world there's also "plesiochronous > buffer" (one of my fave names for this). In my case the use is two fold. I am receiving a bit stream and I need to interleave other data with it at a odd ratio (31:1, 15:1, etc). The interleave ratio also determines a delay in the other bit stream which must be compensated for in the first bit stream with a fixed quantity delay. Then as the first bit stream speeds or slows, the second bit stream clock rate is adjusted to match. The second bit rate is just a simple ratio to the first, so that would not require a PLL. But the output stream is now 32/31 times the bit rate of the first input. This is what the PLL is for. At the other end a similar circuit de-interleaves the two bit streams and a PLL generates the output clock. A similar FIFO adds a delay at this end and the FIFO data count is again used as the phase detector. > I guess since the jobs that it does can different a universal name is > impractical. I would like to think that the name would be based on how the circuit works, not so much on what it is used for. A FIFO is always called a FIFO (or a queue) regardless of how it is being used. Oh, well. The main thing is to get it to work. RickArticle: 139392
On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > i know has been discussed before ;) > > if we leave out the vendor supplied ones (including open source like > mico32) > and the large ones, then my current list: > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE > 10.1 results) > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450 > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for micr= ocode > > ZPU is stack based so most weird, but it has GCC support > C16 has its own assembler/compiler/simulator supplied with source code > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler > available > L8080 (lightweight 8080) not sure if it is correct enogh to run c > compiler code > > I wonder if there are better candidates for each bit-width category > microblaze clone could be considered for 32, but i would rather leave > such clones out from the table > > Antti I'm curious, where did you get the data for your table, in particular the ZPU? I have been following the ZPU closely, reading the mailing list. Although the performance per MHz is not great, they seem to have produced a fairly compact design, much smaller than 1000 LUTs. They do a trade off between LUT usage and program memory by "emulating" some instructions. In reality, this is done like the Intel software interrupt tables. Instead of being executed by the CPU, the opcode specifies an entry point to a code table to perform the function of the instruction. Just in the last week or so, a person working on a pipelined version has gotten over 200 MHz in a Virtex 5 and over 100 MHz in a Spartan 3. It uses 655 LUTs when area optimized and 711 when speed optimized. The author claims 3.3 DMIPS @ 50MHz. I don't know so much about DMIPS, but that sounds pretty slow to me. Clock speed isn't everything. They claim even less LUT usage in other versions with less speed optimizations, but I have not been able to verify this. RickArticle: 139393
On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > i know has been discussed before ;) > > if we leave out the vendor supplied ones (including open source like > mico32) > and the large ones, then my current list: > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE > 10.1 results) > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450 > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for micr= ocode > > ZPU is stack based so most weird, but it has GCC support > C16 has its own assembler/compiler/simulator supplied with source code > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler > available > L8080 (lightweight 8080) not sure if it is correct enogh to run c > compiler code > > I wonder if there are better candidates for each bit-width category > microblaze clone could be considered for 32, but i would rather leave > such clones out from the table > > Antti Oh, BTW, why are you limiting your list to those processors? There are a ton of CPUs on the open cores web site. Of course many of them are not ready for prime time and some aren't even written, just shells that were built for a project idea that never really started. On the other hand, there are many that are not only workable, seem to be quite good. One of the problems with open cores for CPUs is that there is no standard for submission, so anyone can start a CPU design which is listed along side of "real" projects, no matter how far it progresses or what the goal. More than one is just a design to see if it can be done or an educational project. I would like to see more info provided by the authors and to have a summary table available that allows the large list of CPU projects to be quickly evaluated for your purpose. As it is now, everyone who wished to look for a CPU there has to spend hours looking at all of the projects. The "new look" they have come up with does nothing for the functionality that I can see and some of the site still is not working, such as the forums. RickArticle: 139394
On Mar 27, 6:55=A0pm, thomas.sch...@hotmail.fr wrote: > Does anyone know where I could find a xc6200 fpga? I would like to > experiment things on reconfigurable computing and it seems to be the > only fpga with a complete documentation to be fully dynamically > reconfigurable. These chips were only available for a short while. I don't really know why Xilinx produced them and then not only stopped, but seems to have killed them off entirely. I seem to recall that there were projects around to allow you to do any manipulation of the bit stream you wish through a JAVA interface. Not the same as open source tools, but it was supposed to make the same functionality available. RickArticle: 139395
On Mar 27, 9:16=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > For some time I've found it pretty humorous that Xilinx boast of "True > LUT6" in all their Virtex 5+ marketing material. Do they really think > that they can somehow imply that Altera's ALM isn't a "True LUT6" when > in fact it's obvious that the ALM encompasses a LUT6 and much more. > > Or are there some unreal LUT6 out there? I don't know what they are referring to by that. I Lattice provides a dual LUT6 or a single LUT7 in their equivalent to the CLB. I think they do that by combining LUT4 outputs with dedicated muxes. Heck, that's "real" enough for me. I wonder what the advantage of a "real" LUT6 is? :^) RickArticle: 139396
On Mar 28, 10:58=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi > > > i know has been discussed before ;) > > > if we leave out the vendor supplied ones (including open source like > > mico32) > > and the large ones, then my current list: > > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE > > 10.1 results) > > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi= crocode > > > ZPU is stack based so most weird, but it has GCC support > > C16 has its own assembler/compiler/simulator supplied with source code > > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler > > available > > L8080 (lightweight 8080) not sure if it is correct enogh to run c > > compiler code > > > I wonder if there are better candidates for each bit-width category > > microblaze clone could be considered for 32, but i would rather leave > > such clones out from the table > > > Antti > > Oh, BTW, why are you limiting your list to those processors? =A0There > are a ton of CPUs on the open cores web site. =A0Of course many of them > are not ready for prime time and some aren't even written, just shells > that were built for a project idea that never really started. =A0On the > other hand, there are many that are not only workable, seem to be > quite good. > > One of the problems with open cores for CPUs is that there is no > standard for submission, so anyone can start a CPU design which is > listed along side of "real" projects, no matter how far it progresses > or what the goal. =A0More than one is just a design to see if it can be > done or an educational project. =A0I would like to see more info > provided by the authors and to have a summary table available that > allows the large list of CPU projects to be quickly evaluated for your > purpose. =A0As it is now, everyone who wished to look for a CPU there > has to spend hours looking at all of the projects. =A0The "new look" > they have come up with does nothing for the functionality that I can > see and some of the site still is not working, such as the forums. > > Rick Rick I do have a large Excel table where i list all the soft cores, and their features :) will be published soon too i just am trying to use the table for one specific purpose now i know there are tons of cores, and .. many of them useable for some purpose, just the selection and find the right one is not always trivial AnttiArticle: 139397
On Mar 28, 10:51=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi > > > i know has been discussed before ;) > > > if we leave out the vendor supplied ones (including open source like > > mico32) > > and the large ones, then my current list: > > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE > > 10.1 results) > > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi= crocode > > > ZPU is stack based so most weird, but it has GCC support > > C16 has its own assembler/compiler/simulator supplied with source code > > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler > > available > > L8080 (lightweight 8080) not sure if it is correct enogh to run c > > compiler code > > > I wonder if there are better candidates for each bit-width category > > microblaze clone could be considered for 32, but i would rather leave > > such clones out from the table > > > Antti > > I'm curious, where did you get the data for your table, in particular > the ZPU? =A0I have been following the ZPU closely, reading the mailing > list. =A0Although the performance per MHz is not great, they seem to > have produced a fairly compact design, much smaller than 1000 LUTs. > They do a trade off between LUT usage and program memory by > "emulating" some instructions. =A0In reality, this is done like the > Intel software interrupt tables. =A0Instead of being executed by the > CPU, the opcode specifies an entry point to a code table to perform > the function of the instruction. =A0Just in the last week or so, a > person working on a pipelined version has gotten over 200 MHz in a > Virtex 5 and over 100 MHz in a Spartan 3. =A0It uses 655 LUTs when area > optimized and 711 when speed optimized. =A0The author claims 3.3 DMIPS @ > 50MHz. =A0I don't know so much about DMIPS, but that sounds pretty slow > to me. =A0Clock speed isn't everything. > > They claim even less LUT usage in other versions with less speed > optimizations, but I have not been able to verify this. > > Rick Rick the 1000 slice for ZPU wonder me too :( i did just run synthesis on the zpu_med i know it looks awafylly wrong, but i used the results reported the zpu is said to be as small as 400 lut or so, what is way less the 1000 slices i got from ISE test run AnttiArticle: 139398
On Mar 28, 10:51=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 27, 10:13=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi > > > i know has been discussed before ;) > > > if we leave out the vendor supplied ones (including open source like > > mico32) > > and the large ones, then my current list: > > > Core =A0 Datapath width =A0 Spartan-3 slices for small SoC (approx, ISE > > 10.1 results) > > ZPU =A0 =A032 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > C16 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > i8080 =A08 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1000 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 450 > > L8080 8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 150 + 1 BRAM for mi= crocode > > > ZPU is stack based so most weird, but it has GCC support > > C16 has its own assembler/compiler/simulator supplied with source code > > i8080/L8080 are intel 8080 - I assume there is some =A0C compiler > > available > > L8080 (lightweight 8080) not sure if it is correct enogh to run c > > compiler code > > > I wonder if there are better candidates for each bit-width category > > microblaze clone could be considered for 32, but i would rather leave > > such clones out from the table > > > Antti > > I'm curious, where did you get the data for your table, in particular > the ZPU? =A0I have been following the ZPU closely, reading the mailing > list. =A0Although the performance per MHz is not great, they seem to > have produced a fairly compact design, much smaller than 1000 LUTs. > They do a trade off between LUT usage and program memory by > "emulating" some instructions. =A0In reality, this is done like the > Intel software interrupt tables. =A0Instead of being executed by the > CPU, the opcode specifies an entry point to a code table to perform > the function of the instruction. =A0Just in the last week or so, a > person working on a pipelined version has gotten over 200 MHz in a > Virtex 5 and over 100 MHz in a Spartan 3. =A0It uses 655 LUTs when area > optimized and 711 when speed optimized. =A0The author claims 3.3 DMIPS @ > 50MHz. =A0I don't know so much about DMIPS, but that sounds pretty slow > to me. =A0Clock speed isn't everything. > > They claim even less LUT usage in other versions with less speed > optimizations, but I have not been able to verify this. > > Rick Number of BUFGMUXs 1 out of 24 4% Number of MULT18X18SIOs 3 out of 20 15% Number of RAMB16BWEs 16 out of 20 80% Number of Slices 1057 out of 5888 17% Number of SLICEMs 0 out of 2944 0% ZPU_med results without tweaking.. :( seems i need serious optimizing to get down the resource useage AnttiArticle: 139399
On 28 Mrz., 06:45, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > if I use MicroBlaze(tm) Last time I checked there was no registered "microblaze" trademark. Neither in the US nor in Germany. And if there was, it would only prevent you from calling your product "Microblaze". You could still be 100% compatible. > clone on Altera, Lattice > then I suppose it may get unwanted attention, or if not it will get > absolute nil support from the vendors where soft-core marketed > by direct competitor is used. The Microblaze clone is not marketed by Xilinx but by open cores. ISAs can't be protected and the simple single issue implementations hardly use anything that has been patented in the last 25 years. > > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice, > et others > would not mind, as Intel is not FPGA vendor. > and i do not think intel would send C&D either And if they to ignore it. Any patents covering 8080 are long expired and copyright law does not apply (as long as you did not copy any HDL or schematics from them) Please everybody: Don't believe the FUD of the vendors. They try to spread incorrect views on the legal situation. And if I should ever get a C&D from Xilinx I would immediately answer with a C&D regarding the incorrect use of the GPL in the ISE distribution. Well that is a major copyrigh violation on their side. As a side note to extend you list: What about LEON and the other open source versions of SPARC? Did not SUN open source their design? And doesn't openRISC have C-Compiler support? Have fun, Kolja
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