Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
hello I need your help please. I want to connect a gyrocompas(HMC5883L) with a microblaze which is done by I2c and as microblaze does not have the bus I2c. I must add it as a peripheral to the microblaze but I do not know how in EDK regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157751
Ok, I went ahead and ordered the fake chinese Altera USB Blaster programmer= . It was $6.66 including shipping. When I get it in 3-4 weeks I will repor= t on whether it works or not. I am trying to program an XC9572XL CPLD, usi= ng Altera's Quartus II software...Article: 157752
What is the best way to implement a multi channel DDS. I need a DDS that has 8 channels that are time-multiplexed. I am using a Sparatn 6. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157753
Den mandag den 2. marts 2015 kl. 16.03.14 UTC+1 skrev maxascent: > What is the best way to implement a multi channel DDS. I need a DDS that > has 8 channels that are time-multiplexed. I am using a Sparatn 6. > what's wrong with this? http://www.xilinx.com/support/documentation/ip_documentation/dds_compiler/v6_0/pg141-dds-compiler.pdf -LasseArticle: 157754
On 3/2/2015 10:03 AM, maxascent wrote: > What is the best way to implement a multi channel DDS. I need a DDS that > has 8 channels that are time-multiplexed. I am using a Sparatn 6. A DDS circuit is not as simple as some would think and it is not as complex as others would lead you to believe. What you need to be aware of is that they can produce spurs if not carefully designed. That said, I'm not sure what a "multichannel" DDS is. If you mean 8 DDS circuits, then ok, that is clear enough. Are you looking for some way to share the circuitry? The circuitry is not overly complex - it usually consists of a counter or adder to set the phase and a sine look up table to convert the phase to a sine value for the output. If you don't wish to fully duplicate this circuit and your speed requirements are such that you can multiplex the logic, you only need to duplicate the phase step size register and the phase accumulator an add some circuitry to multiplex them through the adder and look up table. This is easy to do in an FPGA by using LUTs as an 8 register bank. If you have a phase offset register that needs to be replicated and muxed as well. If you need low spurs and high resolution to your DAC you can use some approximations to a sine value using the trig function sin(A+B) = sin A cos B + cos A sin B or cos(A+B) = cos A cos B − sin A sin B Either one will do once we make the following approximations... The main one is based on A being the MSBs and B being the LSBs. So A will be a coarse angle over the full 90° and B will always be a very small angle. The main approximation is that cos B will be very close to 1 so that you replace it with 1. Then the first term in each equation will just be one trig lookup for the coarse value if sin A or cos A. The second term can be looked up using the same first table for A and a second table for B which has the fine values, then multiply to get the product. Or you can make another approximation. Since the value of sin B is very small, the second term is going to be very small. This means the error from truncating the A and B inputs to the second term will also be small. So instead of a full size trig table for B you can use a single table with a truncated A and truncated B input with the second term as the output saving the multiplier. This will give you larger spurs than using the full look up tables and performing the multiply, but will save some hardware. In either case the spurs will be *much* smaller than if you simply use the truncated term sin A or cos A. -- RickArticle: 157755
On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote: > hello I need your help please. I want to connect a gyrocompas(HMC5883L) > with a microblaze which is done by I2c and as microblaze does not have > the bus I2c. I must add it as a peripheral to the microblaze but I do > not know how in EDK regards You either need to find some I2C intellectual property that you can build into your project, or you need to make an I2C controller. AFAIK, I2C is a fairly straightforward interface as long as you have pins that can be set to open-drain or tri-stated. I haven't had to do it myself, but I've been on projects where we've had to bit-bang it from a microcontroller, which was accomplished with minimal screaming. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157756
On 3/3/2015 1:45 PM, Tim Wescott wrote: > On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote: > >> hello I need your help please. I want to connect a gyrocompas(HMC5883L) >> with a microblaze which is done by I2c and as microblaze does not have >> the bus I2c. I must add it as a peripheral to the microblaze but I do >> not know how in EDK regards > > You either need to find some I2C intellectual property that you can build > into your project, or you need to make an I2C controller. > > AFAIK, I2C is a fairly straightforward interface as long as you have pins > that can be set to open-drain or tri-stated. I haven't had to do it > myself, but I've been on projects where we've had to bit-bang it from a > microcontroller, which was accomplished with minimal screaming. I2C is not terribly difficult, but the fact that you need to clock from the actual clock line makes it a little more so. At least that is my recollection from looking at the spec. If your system clock is fast enough then you should be able to sample it all in your clock domain. I guess I'm surprised you could do that reliably with bit banging. Perhaps I am thinking of some different protocol... it's been too long, lol. But I do recall there is a way to hang the bus. I think the Intel version of I2C gets around that with a timeout. -- RickArticle: 157757
didaSofi wrote: > hello > I need your help please. I want to connect a gyrocompas(HMC5883L) with a > microblaze which is done by I2c and as microblaze does not have the bus > I2c. I must add it as a peripheral to the microblaze but I do not know how > in EDK > regards > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Do you have the EDK or are you just using the MicroBlaze MCS? The EDK has an I2C peripheral. I think you'll find it under IIC instead of I2C. -- GaborArticle: 157758
On Tue, 03 Mar 2015 14:49:06 -0500, rickman wrote: > On 3/3/2015 1:45 PM, Tim Wescott wrote: >> On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote: >> >>> hello I need your help please. I want to connect a >>> gyrocompas(HMC5883L) >>> with a microblaze which is done by I2c and as microblaze does not have >>> the bus I2c. I must add it as a peripheral to the microblaze but I do >>> not know how in EDK regards >> >> You either need to find some I2C intellectual property that you can >> build into your project, or you need to make an I2C controller. >> >> AFAIK, I2C is a fairly straightforward interface as long as you have >> pins that can be set to open-drain or tri-stated. I haven't had to do >> it myself, but I've been on projects where we've had to bit-bang it >> from a microcontroller, which was accomplished with minimal screaming. > > I2C is not terribly difficult, but the fact that you need to clock from > the actual clock line makes it a little more so. At least that is my > recollection from looking at the spec. If your system clock is fast > enough then you should be able to sample it all in your clock domain. I > guess I'm surprised you could do that reliably with bit banging. Perhaps > I am thinking of some different protocol... it's been too long, lol. > But I do recall there is a way to hang the bus. I think the Intel > version of I2C gets around that with a timeout. IIRC it wasn't too bad if you were the bus master -- having a slow master just made for a slow bus. But, I wasn't the guy cursing the Phillips Semiconductor part and its weirdly unusable interface, then figuring out that it could all be done from I/O pins. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157759
On 3/3/15 2:49 PM, rickman wrote: > On 3/3/2015 1:45 PM, Tim Wescott wrote: >> On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote: >> >>> hello I need your help please. I want to connect a gyrocompas(HMC5883L) >>> with a microblaze which is done by I2c and as microblaze does not have >>> the bus I2c. I must add it as a peripheral to the microblaze but I do >>> not know how in EDK regards >> >> You either need to find some I2C intellectual property that you can build >> into your project, or you need to make an I2C controller. >> >> AFAIK, I2C is a fairly straightforward interface as long as you have pins >> that can be set to open-drain or tri-stated. I haven't had to do it >> myself, but I've been on projects where we've had to bit-bang it from a >> microcontroller, which was accomplished with minimal screaming. > > I2C is not terribly difficult, but the fact that you need to clock from > the actual clock line makes it a little more so. At least that is my > recollection from looking at the spec. If your system clock is fast > enough then you should be able to sample it all in your clock domain. I > guess I'm surprised you could do that reliably with bit banging. Perhaps > I am thinking of some different protocol... it's been too long, lol. > But I do recall there is a way to hang the bus. I think the Intel > version of I2C gets around that with a timeout. > There is no requirement to clock the data in on the rising edge of the clock, there is a moderate amount of required setup time, and normally a lot of hold time (since data changes with the clock high is how you signal start and stop conditions). It is set up so that a simple slave could do most operations on the rising edge of the clock (you can't process start/stop conditions this way), but to be fully conforming you need some filtering as you need to ignore narrow glitches on the signals. You can build a compatible system that is totally synchronous to a fast enough clock. You can probably be reasonably conforming to base speed (100KHz) sampling at only a few MHz (you may have some issue with a hostile master generating marginal, but valid, timing, but you could talk to most devices). Processors can bit bang as master (since the master can chose be be as slow as it wants), but being a slave can be a bit harder without some hardware support. There is a protocol in I2C designed to allow a master to alert a slave (that might be a processor) that it is getting ready to talk, to let the slave devote its attention to the bus. Standard I2C has now time limit built into the cycle, so a device that holds the clock low can hang the bus. There are variations (like SMB) where devices are supposed to have an upper limit on how long they can do this, so as long as they follow the protocol the bus can't be hung (but a broken device can still hang the bus). One suggestion is to look at opencores as it has a number of I2C cores, provided you can live with on open source license.Article: 157760
On 3/3/2015 10:07 PM, Richard Damon wrote: > On 3/3/15 2:49 PM, rickman wrote: >> On 3/3/2015 1:45 PM, Tim Wescott wrote: >>> On Sun, 01 Mar 2015 10:10:45 -0600, didaSofi wrote: >>> >>>> hello I need your help please. I want to connect a gyrocompas(HMC5883L) >>>> with a microblaze which is done by I2c and as microblaze does not have >>>> the bus I2c. I must add it as a peripheral to the microblaze but I do >>>> not know how in EDK regards >>> >>> You either need to find some I2C intellectual property that you can >>> build >>> into your project, or you need to make an I2C controller. >>> >>> AFAIK, I2C is a fairly straightforward interface as long as you have >>> pins >>> that can be set to open-drain or tri-stated. I haven't had to do it >>> myself, but I've been on projects where we've had to bit-bang it from a >>> microcontroller, which was accomplished with minimal screaming. >> >> I2C is not terribly difficult, but the fact that you need to clock from >> the actual clock line makes it a little more so. At least that is my >> recollection from looking at the spec. If your system clock is fast >> enough then you should be able to sample it all in your clock domain. I >> guess I'm surprised you could do that reliably with bit banging. Perhaps >> I am thinking of some different protocol... it's been too long, lol. >> But I do recall there is a way to hang the bus. I think the Intel >> version of I2C gets around that with a timeout. >> > > There is no requirement to clock the data in on the rising edge of the > clock, there is a moderate amount of required setup time, and normally > a lot of hold time (since data changes with the clock high is how you > signal start and stop conditions). It is set up so that a simple slave > could do most operations on the rising edge of the clock (you can't > process start/stop conditions this way), but to be fully conforming you > need some filtering as you need to ignore narrow glitches on the signals. > > You can build a compatible system that is totally synchronous to a fast > enough clock. You can probably be reasonably conforming to base speed > (100KHz) sampling at only a few MHz (you may have some issue with a > hostile master generating marginal, but valid, timing, but you could > talk to most devices). > > Processors can bit bang as master (since the master can chose be be as > slow as it wants), but being a slave can be a bit harder without some > hardware support. There is a protocol in I2C designed to allow a master > to alert a slave (that might be a processor) that it is getting ready to > talk, to let the slave devote its attention to the bus. > > Standard I2C has now time limit built into the cycle, so a device that > holds the clock low can hang the bus. There are variations (like SMB) > where devices are supposed to have an upper limit on how long they can > do this, so as long as they follow the protocol the bus can't be hung > (but a broken device can still hang the bus). > > One suggestion is to look at opencores as it has a number of I2C cores, > provided you can live with on open source license. Looking at others' implementations of unknown quality is not a good substitute for reading and understanding the spec. -- RickArticle: 157761
rickman <gnuarm@gmail.com> wrote: > On 3/3/2015 10:07 PM, Richard Damon wrote: > > One suggestion is to look at opencores as it has a number of I2C cores, > > provided you can live with on open source license. > > Looking at others' implementations of unknown quality is not a good > substitute for reading and understanding the spec. While I don't disagree, we've used the Opencores code successfully. Though you'd have to know enough about the protocol to decide if it suits your use case. The main motivation for us was having something that was reasonably well tested, as opposed to something we made ourselves where we'd have to do the testing. TheoArticle: 157762
One possibility is to implement the waveform as polynomial / spline.
The Horner scheme on Spartan 6 works nicely with four cycles pipeline
delay. In other words, you can run four independent channels using the same
multiplier and one port of a dual-port RAM for coefficients. The second RAM
port can serve a second multiplier => 8 channels.
A "mainstream" DDS would be my first choice - don't fix it if it ain't
broken. The above might work, depending on your application's needs, and
would be fairly compact.
You can find example Verilog code for a four-variable pipelined polynomial
interpolator here, at the bottom of the post ("Pipelined RTL
implementation")
http://www.dsprelated.com/showarticle/594.php
There is a matlab script included to calculate the fixed point
coefficients, e.g. edit the "chirp example"
y = cos(2*pi*x.^2*5);
to a plain sine wave.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 157763
On 3/5/2015 4:43 PM, mnentwig wrote:
> One possibility is to implement the waveform as polynomial / spline.
>
> The Horner scheme on Spartan 6 works nicely with four cycles pipeline
> delay. In other words, you can run four independent channels using the same
> multiplier and one port of a dual-port RAM for coefficients. The second RAM
> port can serve a second multiplier => 8 channels.
>
> A "mainstream" DDS would be my first choice - don't fix it if it ain't
> broken. The above might work, depending on your application's needs, and
> would be fairly compact.
The problem with the mainstream DDS is that for any app where spurs
close to the carrier is a problem, it *is* broken. That's why I
suggested the calculations to extend the precision of the LUT method.
Of course they are only needed if the phase noise is a problem.
> You can find example Verilog code for a four-variable pipelined polynomial
> interpolator here, at the bottom of the post ("Pipelined RTL
> implementation")
>
> http://www.dsprelated.com/showarticle/594.php
>
> There is a matlab script included to calculate the fixed point
> coefficients, e.g. edit the "chirp example"
> y = cos(2*pi*x.^2*5);
> to a plain sine wave.
I don't follow your notation. What does the period after the 'x' mean?
What sort of phase noise does your polynomial generate? Are there spurs
close to the carrier? Many apps need spurs to be -120 dB or so from the
carrier. For some apps the spurs need to be either that low to start
with or are far enough in frequency from the carrier so they can be
filtered to that level.
--
Rick
Article: 157764On 3/5/2015 11:32 AM, Theo Markettos wrote: > rickman <gnuarm@gmail.com> wrote: >> On 3/3/2015 10:07 PM, Richard Damon wrote: >>> One suggestion is to look at opencores as it has a number of I2C cores, >>> provided you can live with on open source license. >> >> Looking at others' implementations of unknown quality is not a good >> substitute for reading and understanding the spec. > > While I don't disagree, we've used the Opencores code successfully. Though > you'd have to know enough about the protocol to decide if it suits your use > case. The main motivation for us was having something that was reasonably > well tested, as opposed to something we made ourselves where we'd have to do > the testing. I understand what you are saying, but how well was the core tested when you got it? I never use code without a thorough verification no matter what the source. In the case of open software I would expect it to come with a test bench with a description of what is being tested and what is not... just as I would write if it were my code. Otherwise I still have to do that and that means I might as well write my own core for the most part. In your case I suppose the fact that most errors were already discovered makes the testing run quicker once you have your test bench, not as many bugs to repair. I'm not saying not to use others' code, I'm just saying it still needs to be thoroughly vetted. -- RickArticle: 157765
Hi Rick, I don't have any hard data on the signal quality as I used this for audio-frequency (modeling a Vox Continental electron organ with something like 96 independent oscillators). Spurs "should" be an implementation issue, but then most things are... Pocket calculators use polynomials for function approximation, so the method itself doesn't worry me. Increasing polynomial order is usually quite effective, compared to increasing lookup table resolution. It might help to use a wider multiplier and more (e.g. 8-stage) pipelining. With 18 bit arithmetics in my example implementation, the total SNR over the whole bandwidth can't exceed 18*6+1.7 ~ 100 dB and the implementation is probably 10 dB worse than that (e.g. 1 LSB error would be 6 dB loss). What makes the method attractive is that multi-channel operation can exploit the pipelining, which is needed anyway to manage the critical path in the Horner scheme calculation. >> y = cos(2*pi*x.^2*5); >I don't follow your notation. What does the period after the 'x' mean? This refers to the matlab script that calculates the polynomial coefficients (link from the blog article). It's Matlab notation for "square every vector entry individually". This example creates a chirp waveform with linearly increasing frequency. To create any other waveform, e.g. a plain sinewave, put it here into the script. Spur performance, I didn't analyze this. Intuitively, I don't see anything that couldn't be "cleaned up" - if nothing else helps, dither the phase accumulator before it goes into the polynomial, lose some wideband SNR but get rid of discrete spurs. In other words: I have used this for heavily multi-channel tone generation, but not to communications-quality requirements. I don't see any hard obstacles, but the proof is left to the reader. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157766
On 3/6/2015 4:40 AM, mnentwig wrote: > Hi Rick, > > I don't have any hard data on the signal quality as I used this for > audio-frequency (modeling a Vox Continental electron organ with something > like 96 independent oscillators). Spurs "should" be an implementation > issue, but then most things are... Of course, but the method used imposes costs for any given requirement for spurs and that is the issue. How complex does the logic need to be for a given quality of signal and in particular, how the specifics of that quality level affects a given application. > Pocket calculators use polynomials for function approximation, so the > method itself doesn't worry me. Increasing polynomial order is usually > quite effective, compared to increasing lookup table resolution. > It might help to use a wider multiplier and more (e.g. 8-stage) pipelining. > With 18 bit arithmetics in my example implementation, the total SNR over > the whole bandwidth can't exceed 18*6+1.7 ~ 100 dB and the implementation > is probably 10 dB worse than that (e.g. 1 LSB error would be 6 dB loss). That depends on the number of taps in the polynomial, which I assume you equate to the number of stages in your pipeline. In that case the number of stages is the number of multipliers, e.g. the cost in terms of logic. > What makes the method attractive is that multi-channel operation can > exploit the pipelining, which is needed anyway to manage the critical path > in the Horner scheme calculation. Utilizing pipelining is a separate issue really. Nearly any method can do that, even a table lookup. >>> y = cos(2*pi*x.^2*5); >> I don't follow your notation. What does the period after the 'x' mean? > > This refers to the matlab script that calculates the polynomial > coefficients (link from the blog article). It's Matlab notation for "square > every vector entry individually". This example creates a chirp waveform > with linearly increasing frequency. To create any other waveform, e.g. a > plain sinewave, put it here into the script. I can't say I follow the notation. > Spur performance, I didn't analyze this. > Intuitively, I don't see anything that couldn't be "cleaned up" - if > nothing else helps, dither the phase accumulator before it goes into the > polynomial, lose some wideband SNR but get rid of discrete spurs. > > In other words: I have used this for heavily multi-channel tone generation, > but not to communications-quality requirements. I don't see any hard > obstacles, but the proof is left to the reader. Ok, thanks. -- RickArticle: 157767
Hi, >> Of course, but the method used imposes costs for any given requirement for spurs and that is the issue. How complex does the logic need to be for a given quality of signal and in particular, how the specifics of that quality level affects a given application. well, the answer could use some better requirements and a couple of days' working time :-) >> That depends on the number of taps in the polynomial, which I assume you equate to the number of stages in your pipeline. In that case the number of stages is the number of multipliers, e.g. the cost in terms of logic. Not necessarily. My example implementation (previous link) maps four channels and all polynomial coefficients to a single multiplier. As audio frequency example, clock it at 100 MHz for a 96 kHz sample rate => 1000 cycles per sample. Use 10 cycles per waveform (e.g. 5th order polynomial plus some overhead) and I can generate 100 independent waveforms using a single multiplier. This can be very compact even with fully independent coefficients, because the overhead is fairly cheap, when address selection in a block ram muxes most of the wide signals. Using one multiplier per polynomial term would be also possible for higher output rate. >>>> y = cos(2*pi*x.^2*5); >I can't say I follow the notation. Never mind that. It's just a line from the Matlab example (link) where I can put the function, for which I want the fixed-point polynomial coefficients. It's fairly straightforward in the context of the Matlab script. >> Utilizing pipelining is a separate issue really. Nearly any method can do that, even a table lookup. Well, yes, true. But for the polynomial, the critical path is comparatively long (i.e. four multiplications in series, each using four cycles delay) so the pipelining makes a big difference. Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157768
On 3/8/2015 5:28 AM, mnentwig wrote: > Hi, > >>> Of course, but the method used imposes costs for any given requirement > for spurs and that is the issue. How complex does the logic need to be for > a given quality of signal and in particular, how the specifics of that > quality level affects a given application. > > well, the answer could use some better requirements and a couple of days' > working time :-) > >>> That depends on the number of taps in the polynomial, which I assume you > equate to the number of stages in your pipeline. In that case the > number of stages is the number of multipliers, e.g. the cost in terms of > logic. > > Not necessarily. My example implementation (previous link) maps four > channels and all polynomial coefficients to a single multiplier. As audio > frequency example, clock it at 100 MHz for a 96 kHz sample rate => 1000 > cycles per sample. Use 10 cycles per waveform (e.g. 5th order polynomial > plus some overhead) and I can generate 100 independent waveforms using a > single multiplier. Yes, here your cost is time rather than logic. That is the tradeoff. If you were doing faster calculations like radar, for example, you would not have the option of multiplexing the hardware. You would need to burn more logic. > This can be very compact even with fully independent coefficients, because > the overhead is fairly cheap, when address selection in a block ram muxes > most of the wide signals. > Using one multiplier per polynomial term would be also possible for higher > output rate. The tradeoff remains. You have to do more work to get a higher precision result with a polynomial, not just in terms of the order of the polynomial, but increased resolution in the multiplies as well. >>>>> y = cos(2*pi*x.^2*5); >> I can't say I follow the notation. > > Never mind that. It's just a line from the Matlab example (link) where I > can put the function, for which I want the fixed-point polynomial > coefficients. > It's fairly straightforward in the context of the Matlab script. Why not just explain your equation in terms I can understand? Are you trying to obfuscate it? >>> Utilizing pipelining is a separate issue really. Nearly any method can > > do that, even a table lookup. > Well, yes, true. But for the polynomial, the critical path is comparatively > long (i.e. four multiplications in series, each using four cycles delay) so > the pipelining makes a big difference. You just gave an example where you had time to perform 1000 multiplies for each result and so used no pipelining. Still, the point remains that pipelining has nothing to do with resolution really. -- RickArticle: 157769
Simulation of your project written in ISE 8.2i, for those using old tools f= or whatever reason, must first compile the necessary libraries. One may str= uggle with getting simulation of their project if CORE Generator was used t= o create components. Within the Xilinx directories: C:\Xilinx\vhdl\src\xilinxcorelib resides the= .vhd files for core generated parts. These files need to be compiled by Mo= delSim PE 10.4. Within the directory: C:\Xilinx\vhdl\src\simprims\README.tx= t are directions vaguely described by the last paragraph. The ModelSim PE 10.4 has provisions a "scripted" command that does the comp= iling of the necessary files. Running the simulation from ISE 8.2i ModelSim= fails to find the xilinxCorelib and halts the simulation. The command comp= xlib -s mti_pe -arch spartan3e was typed into the command line entry of Mod= elSim to find the directory, compiled for use. The command compxlib is inhe= rent in Modelsim and further details of it can be found by typing compxlib = -help and fishing around for your exact needs. Sincerely=20 Cy DrollingerArticle: 157770
Lattice has shipped new version ov their Diamond tool v 3.4.1. for FPGA design. Changelog lists support for new MachXO3LF devices, which I can't find anywhere,. They did hint through some other remark that "F" could stand for devices with real Flash ( instead of 2-time programmable NVCM block in ordinary XO3L) series. Does anyone here know more about XO3LF and possibly any upcoming updates of XO3L ? Lattice has announced bigger models, but then their PR backtracked and pushed those in "full XO3" sufamily, which was to follow XO3L, but did not so far...Article: 157771
On 3/10/2015 9:27 PM, Brane2 wrote: > Lattice has shipped new version ov their Diamond tool v 3.4.1. for FPGA design. > > Changelog lists support for new MachXO3LF devices, which I can't find anywhere,. > > They did hint through some other remark that "F" could stand for devices with real Flash ( instead of 2-time programmable NVCM block in ordinary XO3L) series. > > Does anyone here know more about XO3LF and possibly any upcoming updates of XO3L ? > > Lattice has announced bigger models, but then their PR backtracked and pushed those in "full XO3" sufamily, which was to follow XO3L, but did not so far... I don't keep up with the pre-announced products. But this sounds interesting. My issue with most of the smaller Lattice parts are the fine pitch packages. The X03 devices in general don't seem to be doing anything about that. -- RickArticle: 157772
I have use Chisel for 2 projects with some complexity and a lot of clock do= main.=20 The first is a real time simulator that is able to simulate in real time el= ectrical network. Project has some AD/DA, hundreds of processing core, AXI = master/slave, DDR3, multiple clock domain. The second was a Mandelbrot accelerator with 8 pipelined cores that fill DD= R3 frame buffer and have a UART control link. Good part of Chisel : - increase productivity - Genericity unlocked - Scala possibilities - Check logic loop and don't allow latch Bad part of chisel : - Multi clock support is really not well designed. Usable but very bad - Don't handle conditional blocks on combinatorial signals correctly - Don't allow to do ranged assignments on signals: myBits(3 downto 2) <=3D= XX - Has a poor support of black box, especially with multi clock design - Integrated simulator is bad because it don't allow serious verification = and slow down the global evolution of chisel library - Enum support is not native and is not well designed - Generated Verilog is understandable but with pain - The project has lived and seems stalled (Github) in the fix of his funda= mental issue - You can't use asynchronous reset, only synchronous - Ram support don't fit very well with FPGA (Write to Read) To resume, I had lot of fun with Chisel, Chisel is lot better than VHDL/Ver= ilog in lot of aspect, but is not clean, and I think it never become clean.= It's realy cool for basic project, but when come multi clock, custom reset= and blackbox it's a pain. It's the reason why, some month ago, i have start the development of a new = HDL language (SpinalHDL), inspired by chisel but without his bad parts. The= actual state of the development is really good from my point of view. Need= more test of course, but has all major part implemented and functional. The implementation of UART controller, Single and dual clock FIFO was done = and tested with success. And I'm now looking to enthusiastic people to test= /critic/contribute to this new language :) The git is here: https://github.com/SpinalHDL/SpinalHDL There is 2 example in the readme, more into the lib/ and the test/ If you are interested to contribute to SpinalHDL, tell me. Best regardsArticle: 157773
good morning I want a code C for reading and writing of i2c for the HM5883 sensor. best regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157774
Hi all, I am looking for a generic set of TCL commands (for Synplify) to constrain = _all_ flip-flops which are connected to the same clock enable net with the = same timing constraints. This would be much easier than constraining every = single net on its own. I suppose there should be a set of TCL commands to d= efine those timing constraints. Let me give you an example: I have a CLK frequency of 40 MHz (rising edge) = and all flip-flops in this example design are connected to a clock enable s= ignal. This enable signal takes care that only every second rising edge clo= ck signal is considered. Therefore I want to define a multi-cycle path cons= traint of "2" for all those flip-flops connected to this clock enable signa= l. Does anybody have suggestions for such a set of TCL-based timing constraint= s? Thanks in advance.
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