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
If you express the max frequency as the time of a clock period, it must be longer than the sum of: clock-to-Q delay of a flip-flop or register, plus combinatorial delay from Q to any D input plus set-up time on the D input plus worst-case cycle-to-cycle jitter of the clock. Peter AlfkeArticle: 79976
Hi all! "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:5c9r11ls6l44c5kr1lnj2eq49drtg6fk9h@4ax.com... [snip] > Beware of performing a naive (i.e. literal) translation of your SSI > design into a programmable part. Often designs using individual chips > do things which don't work very well in programmable logic. Some of > these are: > > 1. Gated clocks (to implement clock enables). > 2. Using async resets on flip flops and counters to implement logic > functions. > 3. Hazard coverage. (Usually the tools will optimise out the > "unnecessary" logic.) > > It's usually a trivial matter to turn these into a more FPGA or CPLD > friendly design. > This shouldn't affect the gate count / logic cell count much though. > > Regards, > Allan I don't mean to hijack the thread, but could you possibly elaborate on 1. above? I may need to start and stop a clock generator cleanly inside an FPGA and my initial thought was to use the traditional "gated clock synchronizer" with one d-latch. Am a bit of a noob with FPGAs so I may well be missing something here. DJ --Article: 79977
> it's a deal: You tell us no details, we give you no advice. That's what > you seem to want. I would like to give you guys details... I just don't have the "home-cooked" code on this computer! And I don't think I can say a lot more (not because I don't will, but because my english stinks and because I can't explain it any better). I need to address memory at different speeds. Therefore I need to be able to prescale. I need to address the memory at the same intervals to be able to save data. The data comes from an analog-to-digital converter that should sample different data's with regular intervals (namely at the same speed of the counter). The whole idea is to build the sampling part of an digital oscilloscope. This should include sampling, triggering as in an digital storage oscilloscope. For any further details please ask again! Maybe I forget that I haven't told you what I'm trying to build in details, but I myself don't even know all the details (as I just started the project)! Thanks for helping!Article: 79978
Clock gating has two dangerous aspects: 1. The gate will inevitably delay the active clock edge, which may or may not a problem in your case. 2. Indiscriminate clock gating can generate "runt" clock pulses or clock glitches, which can result in unreliable clocking (some flip-flops reacting, others not). If you use rising-edge clocking, you can enable/disable the clock through an OR gate, whose control input must be synchronous with (clocked by) the rising clock edge. The disabled clock is then parked High, and gets enabled when the clock is High again. Falling-edge clocking does the same with an AND gate, and parks the clock Low. This is safe clock gating, but assumes that the clock is not super-fast. And remember, you must not gate a clock that drives a Digital Clock Manager (Xilinx). Peter Alfke, Xilinx ApplicationsArticle: 79979
Preben, your English is ok, better than my limited Danish. You want to build a sampling scope (so do I). You must start with the A/D vonverter, for that's where most of you money goes. That determines the sampling rate = clock, and you must have low jitter! The rest is not too complicated. You can use on-chip BlockRAM, but you need an interface to external DRAM ( cheap and easily available). I suppose you move all the display and human interface problems onto the PC (that's what I would do). Saves you a lot of work and assures good looks. Now, designig a counter should be the least of your problems... Or, to put it differently: If you have problems with a counter, this project is too big for you. Do something simpler. Good luck. Hilsen Peter AlfkeArticle: 79980
Peter, Lots of thanks for that! And yeah, of course I'm using Xilinx... ;-)) DJ --Article: 79981
Sorry for hanging my question off this thread (should I create a new one in
an instance like this?)
>If you use rising-edge clocking, you can enable/disable the clock
>hrough an OR gate, whose control input must be synchronous with
>(clocked by) the rising clock edge. The disabled clock is then parked
>High, and gets enabled when the clock is High again.
>Falling-edge clocking does the same with an AND gate, and parks the
>clock Low.
Just thinking again, would something along these lines (good old one, unless
I'm mistaken) be the same as your second method:
input CLK_IN;
output CLK_OUT;
input GATE;
reg SYNC_GATE;
always @(negedge CLK_IN)
SYNC_GATE <= GATE;
assign CLK_OUT = CLK_IN & SYNC_GATE;
ASCII schematics for reference:
GATE +---------+ SYNC_GATE
>-------------| D Q |----+
| | |
+---O|>CK | | +-----+
| +---------+ +---| | CLK_OUT
CLK_IN | | & |------>
>--------+-----------------------| |
+-----+
Comments?
DJ
--
Article: 79982"Dr Justice" <sorry@no.spam.wanted> wrote: >I may need to start and stop a clock generator cleanly inside an FPGA and my >initial thought was to use the traditional "gated clock synchronizer" with >one d-latch. Unless you are worried about power consumption it is probably simpler and safer to leave the clock alone and gate whatever it clocks. If the ungated clock is used in the design it will probably already be on a global clock line and available all over the chip. The gated clock will likely have to be buffered and drive another global clock line. The gated clock will be delayed with respect to the ungated clock so you will have difficulty transferring clocked data from the ungated to gated clock domains. Timing analysis and constraints become more difficult. A gated clock may seem like the most obvious solution to your design problem, but, generally it is bad news all round.Article: 79983
>>If you use rising-edge clocking, you can enable/disable the clock >>hrough an OR gate, whose control input must be synchronous with >>(clocked by) the rising clock edge. The disabled clock is then parked >>High, and gets enabled when the clock is High again. >>Falling-edge clocking does the same with an AND gate, and parks the >>clock Low. <SNIP> > > ASCII schematics for reference: > > GATE +---------+ SYNC_GATE > >-------------| D Q |----+ > | | | > +---O|>CK | | +-----+ > | +---------+ +---| | CLK_OUT > CLK_IN | | & |------> > >--------+-----------------------| | > +-----+ Just a comment - if you were to implement this in an FPGA, you would need to (tightly) constrain these paths to control the routing delay. If the routing delay on SYNC_GATE is significantly larger than the path from CLK_IN to the and gate, then you could potentially get a very short clock out pulse. Similarly, CLK_IN taking much longer than SYNC_GATE could also cause problems. Ideally they should be almost matched, with the SYNC_GATE delay being larger than the CLK_IN delay (Of course, it all depends on the speed of your clock). What exactly you can do with this clock (wrt the routing fabric) is another question :) I would have thought that clock enables would almost always be preferable. My 2c, JeremyArticle: 79984
"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net... > > ;-) Also, if he's looking to sell these, he will need to obtain a > > license from Phillips. > > IIRC you do if you want to market it with "I2C" mentioned anywhere, > but if you call it something else (e.g. Two-Wire Interface or TWI) then you > do not. > I see "TWI" in data sheets that look remarkably like I2C at first glance and > may be identical. I see this done also but, according to Philips, it doesn't alleviate the end user of the responsibility of acquiring a license. Here let me quote them, I hope they don't sue me for copyright violations: ============================== "A license is required for implementing an I²C interface on a chip (IC, ASIC, FPGA, etc). It is Philips's position that all chips that can talk to the I²C bus must be licensed. It doesn't matter how this interface is implemented. The licensed manufacturer may use its own know how, purchased IP cores, or whatever. This also applies to FPGAs. However, since the FPGAs are programmed by the user, the user is considered a company that builds an I²C -IC and would need to obtain the license from Philips. " ============================== Well, how do you like that? They see no end to their patent's reach. I maintain, however, that many of their patents have likely expired. I've sure never seen Philips defending their patent on I2C as vehemently as the above quote would indicate. Me thinks they don't want to make to many waves about their "obvious" technique lest they lose out on all the companies that currently pay them. > Then again, they may have just made a mistake in the implementation so that > it doesn't fully meet the I2C spec and they would get sued if a customer > product failed for not meeting the spec. > > > I2C may not be the best choice for the OP. > > I2C is an open-collector bus, great for talking to multiple slaves without > conflict causing damage. > However, it is speed limited by the rate the passive pull-ups can pull up. > SPI is less clever but simpler because it does not need a clever conflict > arbitration scheme. > And faster as well. As long as you need to send data in both directions simultaneously, I suppose it is. It does require 50% more wires though (2-wire I2C vs 3-wire SPI) ;-) Isn't it amazing how no-one needs a ground to communicate? You kinda make SPI sound like a panacea compared to I2C and I disagree with that. Real SPI requires chip select pins for each slave device on the bus, bringing the total number of wires to 3 + number_of_slave_devices (not counting the ground), that's a bit inconvenient and wasteful IMO. There are also I2C devices that have a maximum speed of 2Mhz. AFAIK, SPI is not that much faster than that even with being able to transfer data full duplex. > OP> I am a newbie and am > OP> currently having a project to develop an I2C protocol in VHDL. > > The protocol is already developed and specified. There does seem to be some discrepancy out there as to what constitutes a START condition. Some vendors think you have to bring the clock low after bringing the data low before considering it a START. That's not how Philip's describes it though as they say nothing about bringing the clock low to complete the start condition. > Regarding implementation, I2C slave behaviour should be done with hardware > assistance, while I2C master behaviour is easily implemented by bit-bashing > a pair of open-collector pins. I agree. I've just been doing this for the first time ever with some serial eeproms and a DS1307 real-time clock chip. I like it, it's a cake walk compared to Dallas 1-wire i/o. ;-) > OP> I2C has 2 wires, SCL and SDA; all I have to do is to play with these two > wires? > > Yep. You can even bit-bash I2C master behaviour on an LPT port. > > OP> What else should be considered? > > How will you set the address(es) of the slave(s)? > How will you handle protocol failures (slave not responding, duff data, > etc)? > Is there a CPU in your system? > How will you develop code for the 4005? > IIRC it is obsolete and no longer supported by the Xilinx webpack. > > OP> What I should do next? > > If you've been set this as a university project, and the exercise is > specifically for you to learn I2C, then I guess one is stuck with it. > > If it is your own project, ask if you really need the extra sophistication > of I2C. > Are there ever going to be more than one slave? > If not, the slave arbitration features are pointless. > > > As a further aside, if SPI is not to your liking then you could look at the > Inmos Transputer Link protocol that Inmos developed for high-speed comms > between networked transputers. I have the data sheet I could scan for you. > 20 Mbits/sec, about 2 MByte/sec data rate. That's about 200 times faster > than I2C, and simpler too. > > > > >Article: 79985
Preben Holm wrote: > > The whole idea is to build the sampling part of an digital oscilloscope. > This should include sampling, triggering as in an digital storage > oscilloscope. For that, you need 1:2:5:10:20:50:100 for the best human friendly timebase (rather than a long binary counter). You can code as above, with taps, and a single MUX, or you could have a first stage that can select a choice of divide by /1/2/5/10, as a clock enable into following cascaded /10 stages that select 10/100/1000/10000 etc. If you were being 'register frugal', (eg using a CPLD), then the first stage of /1/2/5/10/20/50 is 6 bits wide, and follow that with a number of /100 cascades [7 bits] The output of this divider chain would be conditioned to be one clock wide, and feed as ClkEnable into the simple binary-memory scanning/loading counter - the scanner counter needs a trigger state engine to Start on Signal trigger, and stop at MAX (or sooner if set). -jgArticle: 79986
Jeremy and nospam, Thank you for the hints! This (non-FPGA legacy) clock is not high speed wrt propagation delays (<20MHz), and the GATE is always of long duration, as in a few tens of CLK_IN periods. I will test it just to observe and learn, but I shall also follow your advice and investigate other ways to do things. DJ P.S. Apologies to Rob Barris for the hijack - I'm done now :) --Article: 79987
Jeremy Stringer <jeremy@_NOSPAM_endace.com> wrote: >>>If you use rising-edge clocking, you can enable/disable the clock >>>hrough an OR gate, whose control input must be synchronous with >>>(clocked by) the rising clock edge. The disabled clock is then parked >>>High, and gets enabled when the clock is High again. >>>Falling-edge clocking does the same with an AND gate, and parks the >>>clock Low. ><SNIP> >> >> ASCII schematics for reference: >> >> GATE +---------+ SYNC_GATE >> >-------------| D Q |----+ >> | | | >> +---O|>CK | | +-----+ >> | +---------+ +---| | CLK_OUT >> CLK_IN | | & |------> >> >--------+-----------------------| | >> +-----+ > >Just a comment - if you were to implement this in an FPGA, you would >need to (tightly) constrain these paths to control the routing delay. > >If the routing delay on SYNC_GATE is significantly larger than the path >from CLK_IN to the and gate, then you could potentially get a very short >clock out pulse. Similarly, CLK_IN taking much longer than SYNC_GATE >could also cause problems. Ideally they should be almost matched, with >the SYNC_GATE delay being larger than the CLK_IN delay (Of course, it >all depends on the speed of your clock). It isn't that bad. The only problem occurs when the delay between CLK_IN to the FF and CLK_IN to the gate exceeds the FF CK to Q delay + the SYNC_GATE delay. That would produce a glitch when the clock is enabled. If CLK_IN is on a global clock line that situation is probably impossible although I am not sure what kind of path there is between a global clock line and 'logic'.Article: 79988
"Anthony Fremont" <spam@anywhere.com> wrote in message news:aQtUd.66873$cW2.23375@fe2.texas.rr.com... > >> I see "TWI" in data sheets > I see this done also but, according to Philips, it doesn't alleviate the > end user of the responsibility of acquiring a license. Here let me > quote them, I hope they don't sue me for copyright violations: > "It is Philips's position that all chips that can talk > to the I²C bus must be licensed." Any microcontroller with two I/O pins that can be switched from 0V to hi-z can talk to the I2C bus. I heard that they didn't mind you making an I2C master that can talk to I2C slaves, since most of their I2C-ready chips were slaves for TV innards etc. and they could not really demand a licence from potential customers. However I heard they did not want to allow people free rein to make competing slave chips, so they did demand a licence fee on that. > Well, how do you like that? They see no end to their patent's reach. > I maintain, however, that many of their patents have likely expired. > I've sure never seen Philips defending their patent on I2C as vehemently > as the above quote would indicate. Me thinks they don't want to make to > many waves about their "obvious" technique lest they lose out on all the > companies that currently pay them. When I was in the consumer electronics arena, word was that Philips developed stuff like the I2C chips for TVs and RC5 / RC6 for their own TVs etc, and their chip making branch was their to serve their consumer goods making branch. They would sell their chips to others to spread the NRE but they would not make much effort to support them. After all you might be a competing TV maker. They made the RC5 standard public but it was not a very tight spec and some manufacturers used unassigned codes for their own purposes. So when they came up with RC6 they didn't bother publicising standards at all. > As long as you need to send data in both directions simultaneously, > I suppose it is. Well, just ignore the stuff you don't want. > It does require 50% more wires though > (2-wire I2C vs. 3-wire SPI) One more wire is not a huge burden. > Isn't it amazing how no-one needs a ground to > communicate? > You kinda make SPI sound like a panacea compared to I2C Not my intention. The OP sounded like he just needed a point to point link, thus the SPI would be good enough. > Real SPI requires chip select pins for each slave device I know. But if he only has the one slave, that's only one pin. > the total number of wires to 3 + > number_of_slave_devices (not counting the ground), True, and I2C tackles that issue. > inconvenient and wasteful IMO. > There are also I2C devices that have a > maximum speed of 2 MHz. That is beyond the I2C spec, which is 100 kbps or 400 kbps in the faster version. I2C slaves are not obliged to run that fast, so you cannot rely on an I2C slave being that fast. > AFAIK, SPI is not that much faster than that But the SPI spec insists on a higher speed, thus if a slave say it uses SPI then the guaranteed speed is higher. > There does seem to be some discrepancy out there as to what constitutes > a START condition. Some vendors think you have to bring the clock low > after bringing the data low before considering it a START. > That's not how Philip's describes it though > as they say nothing about bringing the > clock low to complete the start condition. If Philips own the spec, then what they say _is_ the spec. If other vendors wish to diverge, then they should look out. Maybe Philips should tighten up the spec. I have noticed that I2C slave interface on Microchip's PIC is a crock of shit. It locks up if it gets confused, then doesn't allow you to escape from it by software. >> I2C master behaviour is easily implemented by >> bit-bashing a pair of open-collector pins. > > I agree. I've just been doing this for the first time ever with some > serial EEPROMs and a DS1307 real-time clock chip. I like it, it's a > cake walk compared to Dallas 1-wire i/o. ;-) It is nice eh? Though I did find there were some quirks in various I2C slave chips. My LM75 thermometer isn't talking to me yet! I think it wants a 100 nF decoupler.Article: 79989
Jeremy,neither of us is a fan of clock gating, but I like to explore the limits of "synchronous design". I disagree with your analysis of the need for close delay matching. Let's take the rising edge case with the OR gate. It only requires that the path from clock to Q and to the OR gate has a longer delay than the direct connection of the clock to OR gate. How much longer does not matter, until it approachess the clock High time. I think that's a reasonable assumption, especially since no designer would intentionally delay the clock signal that is to be gated. I had warned against using this trick for very high-frequency clocks. Peter AlfkeArticle: 79990
Anthony Fremont wrote: > "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message > news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net... > >>>;-) Also, if he's looking to sell these, he will need to obtain a >>>license from Phillips. >> >>IIRC you do if you want to market it with "I2C" mentioned anywhere, >>but if you call it something else (e.g. Two-Wire Interface or TWI) > then you do not. >>I see "TWI" in data sheets that look remarkably like I2C at first > glance and may be identical. You can also call it AccessBUS, which is a PC variant. > I see this done also but, according to Philips, it doesn't alleviate the > end user of the responsibility of acquiring a license. Here let me > quote them, I hope they don't sue me for copyright violations: > > ============================== > > "A license is required for implementing an I²C interface on a chip (IC, > ASIC, FPGA, etc). It is Philips's position that all chips that can talk > to the I²C bus must be licensed. It doesn't matter how this interface is > implemented. The licensed manufacturer may use its own know how, > purchased IP cores, or whatever. > > This also applies to FPGAs. However, since the FPGAs are programmed by > the user, the user is considered a company that builds an I²C -IC and > would need to obtain the license from Philips. " > > ============================== > > Well, how do you like that? They see no end to their patent's reach. > I maintain, however, that many of their patents have likely expired. > I've sure never seen Philips defending their patent on I2C as vehemently > as the above quote would indicate. Me thinks they don't want to make to > many waves about their "obvious" technique lest they lose out on all the > companies that currently pay them. Maybe, but I have a Philips data book IC12 that states : " i2c BUS based system designs require no special license, and the i2c bus protocol is easily implemented by virtually any microcontroller on the market" i2c IS a trademark, and so if you want to get the perceived marketing of that trademark, and use it in your DOCs, Philips have to give the OK. <snip> > There are also I2C devices that have a > maximum speed of 2Mhz. AFAIK, SPI is not that much faster than that > even with being able to transfer data full duplex. i2c has Speed nodes at 100Khz, 400KHz, 1MHz, and 3.4MHz, but few devices can be found at 3.4MHz.... SPI is now commonly spec'd to 25MHz, and some devices are 50MHz. Some SPI designs use a RING scheme, which removes the multiple chip-select issues. With most SPI HW ports in uC, they fully support this RING alternative. Using as FPGA-FPGA there is no strict need to stick to anyt of the i2c speeds, and if you deployed it using CAN BUS buffers (or wired-OR configured RS422 devices) you could probably get i2c over 20MHz -jgArticle: 79991
>If this is just a one-off or very low volume device that doesn't require > a high-efficiency power source, why wouldn't you use an LDO? They're >easy! Although switchers, etc, are getting easier and more reliable, >they're more complicated -- just in component count alone. Beware. Modern LDO regulators have restrictions on the ESR of the filter caps. Too low or too high and they oscillate. I'm far from a wizard on this topic. But I got burned several years ago so it's on my hot-list of things to check carefully and then still be suspicious. I think older non-LDO type linear regulators are easier to work with. But they often don't go down to 1.2V. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 79992
I just upgraded from Quartus 4.1 SP2 to Quartus 4.2 SP1 and encounter a very strange problem. If I try to compile a project, it fails before fitting with a flexLM error 88, something about time having gone backwards. By much trial and error I found that the problem seems to be linked to the project living on a Linux (SuSE 9.2) Samba server. If I copy it to the local directory, everything works fine. I've double checked that both the client and server machine are within seconds of each other and I never had such a problem with the previous version of Quartus. Any ideas? (Other than working out of a local directory). Thanks, TommyArticle: 79993
Tommy Thorn wrote:
> I just upgraded from Quartus 4.1 SP2 to Quartus 4.2 SP1 and encounter a
> very strange problem. If I try to compile a project, it fails before
> fitting with a flexLM error 88, something about time having gone backwards.
Recent FlexLM releases check some set of file dates to judge if the
system clock has been set back to use an expired license. This test can
convict the innocent. Try making a fresh directory on the server
and copying just the sources files over from the local directory. Check
all the file dates and touch them up if necessary before compiling.
-- Mike Treseler
Article: 79994So does it mean that if my design size is less than 5M (xilinx gates ;-)) and i am not using the specific features of virtex-II then will I get the same performance in both spartenIII and virtex2???Article: 79995
Dear Sirs! We have developed the board with LXT970AQC and have the following problem: At power on autonegotiation switches to 10 Mbps while I have 100 Mbps hub and 100 Mbps Ethernet at PC. At 10 Mbps all is OK. But when I force chip to work in 100 Mbps mode I get RX_CLK low. All LEDs are off except "100 Mbps" inspite of intensive traffic. No data can be sent to the network and no data can be received. In the same time I have a connection to network at PC when the board is connected directly to PC, and the LED on hub is on when I connect the board to the hub. And the data at ethernet line seems to be OK. What can be the problem? All the best, Eugene Fedunin RDC ReagentArticle: 79996
Can anyone tell me if it is possible to update from Xilinx EDK 6.1.xx to EDK 6.3.xx. It appears that I need to buy a new copy of the EDK to be able to update from EDK 6.1 LinasArticle: 79997
Preben Holm wrote:
> Göran Bilski wrote:
>
>> Hi,
>>
>> When using Xilinx, the SRL16 is a very good candidate for prescaler
>> implementation.
>>
>
> In which way would you use this shift register LUT for prescaler
> implementation!
Hi,
SRL16 is a 16 deep shift-register and if you clock in a '1' it will take 16
clock before it appears on the output.
If you connect the output to the input and initialize the SRL16 with "0001" you
will have a counter which have an output to '1' every 16 clock cycle.
Now if you take that output and connect to another SRL16 clock enable input.
The second SRL16 will also have "0001" as the init value.
The output of this SRL16 will change every 16 clock cycles and the output will
be high for 16 clock cycles and low for 240 clock cycles.
If we clean this output to only be high for 1 clock cycle and low for 255
cycles, we can chain these SRL16 together to create any size of prescalers.
The cleaning is simple and uses only 2 DFF.
Now this will create a 8-bit prescaler using 2 LUTs and 2 DFFs.
To count other values than 2^n is also possible.
Each SRL16 has a 4-bit input value which determines the length of the shift
register. The above used all '1' which would delay the input signal 16 clock cycles.
ex. To have a prescaler of 1404, we need to find values between 1-16 than this
number can be built from.
In this case 12*13*9 = 1404
So we need 3 SRL16, with values of 11,12,8
Some values can be broken into smaller pieces like prime numbers. These values
can't use SRL16 as a prescaler.
I have used this for creating baudrate generators and I have attached some VHDL
code which will automate this process.
It also have some extra features.
1. When doing baudrate generators, the prescaler doesn't have to be exact. UART
allows some skews. I have added this as a parameter to the baudrate module. The
VHDL code will search for good SRL16 numbers around the requested prescaler
numbers within the skew limits.
2. If the VHDL code, can't find any good SRL16 values, it will automatically
fall back to a standard n-bit counter which always works but it's larger.
3. Since this was used for a UART baudrate, it can also have a dynamic baudrate
but then it uses a standard counter since the baudrate needs to change
dynamically. It could use SRL16 since UART baudrates normally is a multiply of
each other. I can add one extra SRL16 which would create 1-16x multiply of the
lowest baudrate. I will probably add this sometimes.
This code is a good example of the strength of VHDL.
If you only need small prescaler values, the saving is not that much but it will
save some logic for large values.
Göran
<<<<< VHDL CODE >>>>>
-------------------------------------------------------------------------------
-- $Id$
-------------------------------------------------------------------------------
-- divide_part.vhd - Entity and architecture
--
-- ***************************************************************************
-- ** Copyright(C) 2005 by Xilinx, Inc. All rights reserved. **
-- ** **
-- ** This text contains proprietary, confidential **
-- ** information of Xilinx, Inc. , is distributed by **
-- ** under license from Xilinx, Inc., and may be used, **
-- ** copied and/or disclosed only pursuant to the terms **
-- ** of a valid license agreement with Xilinx, Inc. **
-- ** **
-- ** Unmodified source code is guaranteed to place and route, **
-- ** function and run at speed according to the datasheet **
-- ** specification. Source code is provided "as-is", with no **
-- ** obligation on the part of Xilinx to provide support. **
-- ** **
-- ** Xilinx Hotline support of source code IP shall only include **
-- ** standard level Xilinx Hotline support, and will only address **
-- ** issues and questions related to the standard released Netlist **
-- ** version of the core (and thus indirectly, the original core source). **
-- ** **
-- ** The Xilinx Support Hotline does not have access to source **
-- ** code and therefore cannot answer specific questions related **
-- ** to source HDL. The Xilinx Support Hotline will only be able **
-- ** to confirm the problem in the Netlist version of the core. **
-- ** **
-- ** This copyright and support notice must be retained as part **
-- ** of this text at all times. **
-- ***************************************************************************
--
-------------------------------------------------------------------------------
-- Filename: divide_part.vhd
--
-- Description:
--
-- VHDL-Standard: VHDL'93
-------------------------------------------------------------------------------
-- Structure:
-- divide_part.vhd
--
-------------------------------------------------------------------------------
-- Author: goran
-- Revision: $Revision$
-- Date: $Date$
--
-- History:
-- goran 2005-02-28 First Version
--
-------------------------------------------------------------------------------
-- Naming Conventions:
-- active low signals: "*_n"
-- clock signals: "clk", "clk_div#", "clk_#x"
-- reset signals: "rst", "rst_n"
-- generics: "C_*"
-- user defined types: "*_TYPE"
-- state machine next state: "*_ns"
-- state machine current state: "*_cs"
-- combinatorial signals: "*_com"
-- pipelined or register delay signals: "*_d#"
-- counter signals: "*cnt*"
-- clock enable signals: "*_ce"
-- internal version of output port "*_i"
-- device pins: "*_pin"
-- ports: - Names begin with Uppercase
-- processes: "*_PROCESS"
-- component instantiations: "<ENTITY_>I_<#|FUNC>
-------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
entity Divide_part is
generic (
Ratio : natural;
First : boolean := true
);
port (
Clk : in std_logic;
Clk_En : in std_logic;
Clk_En_Out : out std_logic
);
end entity Divide_part;
library unisim;
use unisim.all;
library ieee;
use ieee.numeric_std.all;
architecture VHDL_RTL of Divide_part is
component SRL16E is
-- pragma translate_off
generic (
INIT : bit_vector := X"0000");
-- pragma translate_on
port (
Q : out std_logic;
A0 : in std_logic;
A1 : in std_logic;
A2 : in std_logic;
A3 : in std_logic;
CE : in std_logic;
Clk : in std_logic;
D : in std_logic
);
end component SRL16E;
component SRLC16E is
-- pragma translate_off
generic (
INIT : bit_vector := X"0000");
-- pragma translate_on
port (
Q : out std_logic;
Q15 : out std_logic;
A0 : in std_logic;
A1 : in std_logic;
A2 : in std_logic;
A3 : in std_logic;
CE : in std_logic;
Clk : in std_logic;
D : in std_logic
);
end component SRLC16E;
signal loop_Bit : std_logic;
attribute INIT : string;
constant Nr_Of_SRL16 : natural := 1 + ((Ratio-1)/16);
constant Last_SRL16_Ratio : natural := ((Ratio-1) mod 16);
constant A : std_logic_vector(3 downto 0) :=
std_logic_vector(to_unsigned(Last_SRL16_Ratio, 4));
signal shifts : std_logic_vector(0 to Nr_Of_SRL16);
signal Emptys : std_logic_vector(0 to Nr_Of_SRL16);
begin -- architecture VHDL_RTL
One_SRL16 : if (Nr_Of_SRL16 = 1) generate
attribute INIT of SRL16E_I : label is "0001";
begin
SRL16E_I : SRL16E
-- pragma translate_off
generic map (
INIT => X"0001") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => loop_Bit, -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => A(0), -- [in std_logic]
A1 => A(1), -- [in std_logic]
A2 => A(2), -- [in std_logic]
A3 => A(3), -- [in std_logic]
Q => loop_Bit); -- [out std_logic]
end generate One_SRL16;
Two_SRL16 : if (Nr_Of_SRL16 = 2) generate
attribute INIT of SRLC16E_1 : label is "0001";
attribute INIT of SRL16E_2 : label is "0000";
begin
-- The first SRLC16E
SRLC16E_1 : SRLC16E
-- pragma translate_off
generic map (
INIT => X"0001") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => loop_Bit, -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => '1', -- [in std_logic]
A1 => '1', -- [in std_logic]
A2 => '1', -- [in std_logic]
A3 => '1', -- [in std_logic]
Q15 => shifts(1), -- [out std_logic]
Q => Emptys(1)); -- [out std_logic]
SRL16E_2 : SRL16E
-- pragma translate_off
generic map (
INIT => X"0000") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => shifts(1), -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => A(0), -- [in std_logic]
A1 => A(1), -- [in std_logic]
A2 => A(2), -- [in std_logic]
A3 => A(3), -- [in std_logic]
Q => loop_Bit); -- [out std_logic]
end generate Two_SRL16;
More_Than_Two : if (Nr_Of_SRL16 > 2) generate
attribute INIT of SRLC16E_1 : label is "0001";
attribute INIT of SRL16E_n : label is "0000";
begin
-- The first SRLC16E
SRLC16E_1 : SRLC16E
-- pragma translate_off
generic map (
INIT => X"0001") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => loop_Bit, -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => '1', -- [in std_logic]
A1 => '1', -- [in std_logic]
A2 => '1', -- [in std_logic]
A3 => '1', -- [in std_logic]
Q15 => shifts(1), -- [out std_logic]
Q => Emptys(1)); -- [out std_logic]
The_Rest : for I in 2 to Nr_Of_SRL16-2 generate
attribute INIT of SRLC16E_I : label is "0000";
begin
SRLC16E_I : SRLC16E
-- pragma translate_off
generic map (
INIT => X"0000") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => shifts(I-1), -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => '1', -- [in std_logic]
A1 => '1', -- [in std_logic]
A2 => '1', -- [in std_logic]
A3 => '1', -- [in std_logic]
Q15 => shifts(I), -- [out std_logic]
Q => Emptys(I)); -- [out std_logic]
end generate The_Rest;
-- The last SRL16
SRL16E_n : SRL16E
-- pragma translate_off
generic map (
INIT => X"0000") -- [bit_vector]
-- pragma translate_on
port map (
CE => Clk_En, -- [in std_logic]
D => shifts(Nr_Of_SRL16-2), -- [in std_logic]
Clk => Clk, -- [in std_logic]
A0 => A(0), -- [in std_logic]
A1 => A(1), -- [in std_logic]
A2 => A(2), -- [in std_logic]
A3 => A(3), -- [in std_logic]
Q => loop_Bit); -- [out std_logic]
end generate More_Than_Two;
-----------------------------------------------------------------------------
-- If the SRL16 is the first in a serie then the output is a clean single
-- clock pulse
-----------------------------------------------------------------------------
Is_First : if (First) generate
Clk_En_Out <= loop_Bit;
end generate Is_First;
-----------------------------------------------------------------------------
-- If not the first the output has to be masked so that it produce a single
-- clock pulse
-----------------------------------------------------------------------------
not_First : if (not First) generate
signal Out1 : std_logic;
begin
Out1_DFF : process (Clk) is
begin -- process Out1_DFF
if Clk'event and Clk = '1' then -- rising clock edge
Out1 <= loop_Bit;
end if;
end process Out1_DFF;
Out2_DFF : process (Clk) is
begin -- process Out2_DFF
if Clk'event and Clk = '1' then -- rising clock edge
if (Out1 = '1') then
Clk_En_Out <= Clk_En;
end if;
end if;
end process Out2_DFF;
end generate not_First;
end architecture VHDL_RTL;
-------------------------------------------------------------------------------
-- $Id$
-------------------------------------------------------------------------------
-- baudrate.vhd - Entity and architecture
--
-- ***************************************************************************
-- ** Copyright(C) 2005 by Xilinx, Inc. All rights reserved. **
-- ** **
-- ** This text contains proprietary, confidential **
-- ** information of Xilinx, Inc. , is distributed by **
-- ** under license from Xilinx, Inc., and may be used, **
-- ** copied and/or disclosed only pursuant to the terms **
-- ** of a valid license agreement with Xilinx, Inc. **
-- ** **
-- ** Unmodified source code is guaranteed to place and route, **
-- ** function and run at speed according to the datasheet **
-- ** specification. Source code is provided "as-is", with no **
-- ** obligation on the part of Xilinx to provide support. **
-- ** **
-- ** Xilinx Hotline support of source code IP shall only include **
-- ** standard level Xilinx Hotline support, and will only address **
-- ** issues and questions related to the standard released Netlist **
-- ** version of the core (and thus indirectly, the original core source). **
-- ** **
-- ** The Xilinx Support Hotline does not have access to source **
-- ** code and therefore cannot answer specific questions related **
-- ** to source HDL. The Xilinx Support Hotline will only be able **
-- ** to confirm the problem in the Netlist version of the core. **
-- ** **
-- ** This copyright and support notice must be retained as part **
-- ** of this text at all times. **
-- ***************************************************************************
--
-------------------------------------------------------------------------------
-- Filename: baudrate.vhd
--
-- Description:
--
-- VHDL-Standard: VHDL'93
-------------------------------------------------------------------------------
-- Structure:
-- baudrate.vhd
--
-------------------------------------------------------------------------------
-- Author: goran
-- Revision: $Revision$
-- Date: $Date$
--
-- History:
-- goran 2005-02-28 First Version
--
-------------------------------------------------------------------------------
-- Naming Conventions:
-- active low signals: "*_n"
-- clock signals: "clk", "clk_div#", "clk_#x"
-- reset signals: "rst", "rst_n"
-- generics: "C_*"
-- user defined types: "*_TYPE"
-- state machine next state: "*_ns"
-- state machine current state: "*_cs"
-- combinatorial signals: "*_com"
-- pipelined or register delay signals: "*_d#"
-- counter signals: "*cnt*"
-- clock enable signals: "*_ce"
-- internal version of output port "*_i"
-- device pins: "*_pin"
-- ports: - Names begin with Uppercase
-- processes: "*_PROCESS"
-- component instantiations: "<ENTITY_>I_<#|FUNC>
-------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
entity Baud_Rate is
generic (
C_USE_FIXED : integer := 1; -- Fixed baudrate
C_RATIO : integer := 814; -- The ratio between clk and the asked
-- baudrate multiplied with 16
C_INACCURACY : integer := 15 -- The maximum inaccuracy of the clk
); -- division in per thousands
port (
Clk : in std_logic;
Div_Factor : in std_logic_vector(0 to 15);
EN_16x_Baud : out std_logic);
end entity Baud_Rate;
library unisim;
use unisim.all;
architecture VHDL_RTL of Baud_Rate is
component MUXCY_L is
port (
DI : in std_logic;
CI : in std_logic;
S : in std_logic;
LO : out std_logic);
end component MUXCY_L;
component XORCY is
port (
LI : in std_logic;
CI : in std_logic;
O : out std_logic);
end component XORCY;
component Divide_Part is
generic (
Ratio : natural;
First : boolean);
port (
Clk : in std_logic;
Clk_En : in std_logic;
Clk_En_Out : out std_logic);
end component Divide_Part;
-- log2 function returns the number of bits required to encode x choices
function log2(x : natural) return integer is
variable i : integer := 0;
begin
if x = 0 then return 0;
else
while 2**i < x loop
i := i+1;
end loop;
return i;
end if;
end function log2;
-----------------------------------------------------------------------------
-- Calculate the number of SRL16s needed for the Ratio R
-----------------------------------------------------------------------------
constant MAX_DIV_FACTOR : natural := 16;
subtype SRL16_DIV_TYPE is natural range 2 to MAX_DIV_FACTOR;
type FACTORS_LIST_TYPE is array (natural range 1 to 15) of SRL16_DIV_TYPE;
type FACTORS_TYPE is
record
Good_Divide : boolean;
Nr_Of_Factors : natural;
Factor_List : FACTORS_LIST_TYPE;
end record FACTORS_TYPE;
-----------------------------------------------------------------------------
-- Trying to divide R into integer values of values 2-16 until the end result
-- is between 2-16.
-----------------------------------------------------------------------------
function Get_Factors (R : natural) return FACTORS_TYPE is
variable N : natural := R;
variable Result : FACTORS_TYPE;
variable no : natural := 1;
variable Found : boolean;
begin -- function Get_Factors
if (N < 16) then
Result.FACTOR_LIST(1) := N;
Result.Nr_Of_Factors := 1;
Result.Good_Divide := true;
return Result;
end if;
while N /= 1 loop
Found := false;
for I in 16 downto 2 loop
if ((N mod I = 0)) then -- Found factor
Result.FACTOR_LIST(no) := I;
N := N / I;
no := no + 1;
Found := true;
exit;
end if;
end loop; -- I
if (not(Found)) then
Result.Good_Divide := false;
exit;
end if;
end loop;
if (found) then
Result.Good_Divide := true;
Result.Nr_Of_Factors := no-1;
end if;
return Result;
end function Get_Factors;
-----------------------------------------------------------------------------
-- Trying to find a ratio that is within 1.5% of the asked ratio and that the
-- ratio can be implemented with SRL16.
-----------------------------------------------------------------------------
function Find_Best_Factors (R : natural) return FACTORS_TYPE is
constant Proc_Diff : natural := R*C_INACCURACY/1000; -- Calculate the max
difference
-- for the maximum inaccuracy
variable Result : FACTORS_TYPE;
begin -- function Find_Best_Factors
Result := Get_Factors(R);
if (Result.Good_Divide) then
return Result;
end if;
for I in 1 to Proc_Diff loop
Result := Get_Factors(R+I);
if (Result.Good_Divide) then
return Result;
end if;
Result := Get_Factors(R-I);
if (Result.Good_Divide) then
return Result;
end if;
end loop; -- I
Result.Good_Divide := false;
return Result;
end function Find_Best_Factors;
constant Divide_Factors : FACTORS_TYPE := Find_Best_Factors(C_RATIO);
signal Clk_En_I : std_logic_vector(0 to Divide_Factors.Nr_Of_Factors);
signal Count : std_logic_vector(0 to 15);
begin -- architecture VHDL_RTL
Using_Fixed_Baudrate : if (C_USE_FIXED /= 0) generate
-----------------------------------------------------------------------------
-- A clean and good ratio was found that was within the 1.5% limit, so
-- implement the uartlite division using SRL16s
-----------------------------------------------------------------------------
Using_SRL16s : if (Divide_Factors.Good_Divide) generate
Clk_En_I(0) <= '1';
SRL16s : for I in 1 to Divide_Factors.Nr_Of_Factors generate
Divide_I : Divide_Part
generic map (
Ratio => Divide_Factors.FACTOR_LIST(I), -- [natural range 2 to 16]
First => (I = 1)) -- [boolean]
port map (
Clk => Clk, -- [in std_logic]
Clk_En => Clk_En_I(I-1), -- [in std_logic]
Clk_En_Out => Clk_En_I(I)); -- [out std_logic]
end generate SRL16s;
En_16x_Baud <= Clk_En_I(Divide_Factors.Nr_Of_Factors);
end generate Using_SRL16s;
-----------------------------------------------------------------------------
-- Couldn't find a good ratio within the 1.5% limit so implement the uartlite
-- generation using a standard counter
-----------------------------------------------------------------------------
Using_Counter : if (not Divide_Factors.Good_Divide) generate
constant Nr_Of_Bits : natural := log2(C_RATIO-1);
constant New_Value : std_logic_vector(0 to Nr_Of_Bits-1) :=
std_logic_vector(to_unsigned(C_RATIO-1, Nr_Of_Bits));
signal Cnt : std_logic_vector(0 to Nr_Of_Bits-1);
signal New_Cnt : std_logic_vector(0 to Nr_Of_Bits-1);
signal Carry : std_logic_vector(0 to Nr_Of_Bits);
signal Count : std_logic_vector(0 to Nr_Of_Bits-1);
begin
Carry(0) <= '0'; -- Always subracting
All_Bits : for I in 0 to Nr_Of_Bits-1 generate
New_Cnt(I) <= not(Count(I)) when Carry(Nr_Of_Bits) = '0' else New_Value(I);
MUXCY_L_I1 : MUXCY_L
port map (
DI => '0', -- [in std_logic]
CI => Carry(I), -- [in std_logic]
S => New_Cnt(I), -- [in std_logic]
LO => Carry(I+1)); -- [out std_logic]
XORCY_I1 : XORCY
port map (
LI => New_Cnt(I), -- [in std_logic]
CI => Carry(I), -- [in std_logic]
O => Cnt(I)); -- [out std_logic]
end generate All_Bits;
Counter : process (Clk) is
begin -- process Counter
if Clk'event and Clk = '1' then -- rising clock edge
Count <= Cnt;
end if;
end process Counter;
En_16x_Baud <= Carry(Nr_Of_Bits);
end generate Using_Counter;
end generate Using_Fixed_Baudrate;
Dynamic_Baudrate: if (C_USE_FIXED = 0) generate
Counter : process (Clk) is
begin -- process Counter
if Clk'event and Clk = '1' then -- rising clock edge
if (Count = "0000000000000000") then
Count <= Div_Factor;
EN_16x_Baud <= '1';
else
Count <= std_logic_vector(unsigned(Count) - 1);
EN_16x_Baud <= '0';
end if;
end if;
end process Counter;
end generate Dynamic_Baudrate;
end architecture VHDL_RTL;
Article: 79998Seems like you like Transputers as well. In my master thesis I built transputer boards and liked the hardware. Occam was a bit weird but functional for the purpose. If you liked the transputer links, you will also like the MicroBlaze FSL connections. It will allow you to built the same kind of systems but with higher bandwidth. The FSL are 32-bit wide compared to 4-bit on the transputer link. Göran Bilski DerekSimmons@FrontierNet.net wrote: > For me to answer your question let me tell you a little bit about > myself. In the fall of 1987 I entered college at RIT. I was exposed to > a lot of new computer hardware. Growing up I was exposed to computers > designed for data processing. I bought a Commodore Amiga to do my > school work on and it turned out to be an excellent choice because it > allowed me to work files from IBM PC and Apple Macintosh environments. > Remember at this time IBM's were still primarily CGA (4 colors - > cyan, white, magenta and black) and Macintosh's were black and white. > Commodore Amiga had a quasi-12-bit color mode called HAM. For > recreation one of the first freeware applications I discovered > raytracers. The Commodore Amiga was a 16/32-bit MC68000 at about 14 Mhz > (IBMs were 16, 20, 25 and Mac was 8 Mhz). In some of my free time > between classes I spent time at the library researching different ways > to accelerate raytracing. The first and most obvious way was to buy an > accelerator or co-processor card with a faster processor and floating > point co-processor. I think it was in byte magazine I saw an article on > Transputers and I had read articles on transputer products being > developed for the Amiga. I saved my money while waited for the products > to be completed but eventually the projects were canceled. Late one > winter with the money saved I bought a CSA Education Kit. I could > compile and run transputer applications on an IBM bridge card and the > copy them to the Amiga file system and view them from the Workbench > desktop. I also made it a habit of visiting Rochester's surplus shops > and through dump luck I found a factory tray of eight T800s. The guy > who ran the shop didn't know what they were, seeing that they were > gold told me he would have to charge me a premium for them, $10. Using > a Vector prototyping board I connected the eight processors to the CSA > card. I just wired them up so that they could properly reset. I > didn't have money buy any memory so I just used the on chip ram. I > could implement a very small raytracer and when I out grew the memory > of one processor I would pair them up. Eventually I had a tightly > coupled processor made up of an arrangement of 8 transputers in a cube > topology. I think it was about a year later I was a HAM radio flea > market found my next upgrade. This guy and his son brought a real truck > load of junk. I remember him have bar code scanners, data entry pads, > and parts of old telephone system. One of things I found was a black PC > expansion case. The front was ripped off, on the back I could see the > rows of 37 pin connectors and through the vents I could see the tops of > gold chips. I asked him how much it was. He told me it was marked and > came over and found the price for me. He charged me $20 for it. The > friend with asked me what I bought and I told him I'm not sure but > I'll show you. We took it back to the car where I removed the top. > Inside where 5 CSA 4 transputer boards, a crossbar board, an INMOS B008 > with the graphics TRAM and who ever had it had tucked the cable for the > graphics TRAM inside. My transputer setup had moved from the Amiga to a > dedicated Everex Step 386/33 Mhz. My raytracer evolved into a hypercube > and I was able to let the main rendering routine recurse more or I > added on more features. As time went on, the topology evolved into a > sophisticated pipe line. A few years after graduating from college I > started buying them through eBay. My system is split between an > industrial PC, the old black PC expansion case and a VME cabinet. The > last time I spent anytime doing anything with I was having problems > with the worm program that maps the network. I could determine if the > network had gotten so big it was timing out before it had finished > discover the network or if there was a hardware failure. I do follow > the other news group (comp.sys.transputer). I haven't compared it to > a modern PC, currently it I have a PIII 500 Mhz laptop and dual 733 Mhz > desktop. But it would require a rewrite to take advantage of the PC > threading architecture. > > I bought the NIOS II Development kit because I liked the development > tools and I can see the potential for doing the same kind of things > that I have done with transputers. I bought the kit and a Lancelot > video adaptor. I plan on developing a 3D graphics core for it with a > similar api to OpenGL with intentions of making it into a commercial > product. With the Stratix II development board, I see the SDRAM as the > biggest bottle neck. I have sketched out an elaborate buffering system > that should alleviate this. I would also like to be able to configure > the resolution and color depth from software. When I roll it over as a > core the wizard would give the engineer the option of letting it be > programmable with default values or hard code the settings. > > I have been poking around the couple of days about and have found a > couple of post about engineers implementing multi-processor systems. I > would say have of them sounded like student projects. If anybody has > implemented multi-processors systems I would like to hear about their > experiences and any after thoughts from the experience. Since a lot of > this is still new to me, I'm still at the steep part of the learning > curve, I would appreciate if anybody has any projects that they can > share with me. > > Derek >Article: 79999
Hi, I think the virtex-2 still has a faster clock, besides that I think you are right. Maybe some special DSP implementations need more gates on the Spartan, because it doesnt have as much special DSP functionality... regards, Ben
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