Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 79975

Article: 79975
Subject: Re: maximum freq of operation of a circuit
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Feb 2005 11:38:24 -0800
Links: << >>  << T >>  << A >>
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 Alfke


Article: 79976
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Dr Justice" <sorry@no.spam.wanted>
Date: Sun, 27 Feb 2005 22:28:44 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Prescalable counter
From: Preben Holm <64bitNOnoSPAMno@mailme.dk>
Date: Sun, 27 Feb 2005 22:53:58 +0100
Links: << >>  << T >>  << A >>

> 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
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Feb 2005 14:03:36 -0800
Links: << >>  << T >>  << A >>
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 Applications


Article: 79979
Subject: Re: Prescalable counter
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Feb 2005 14:44:28 -0800
Links: << >>  << T >>  << A >>
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 Alfke


Article: 79980
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Dr Justice" <sorry@no.spam.wanted>
Date: Sun, 27 Feb 2005 23:54:01 +0100
Links: << >>  << T >>  << A >>
Peter,

Lots of thanks for that!

And yeah, of course I'm using Xilinx...  ;-))

DJ
--



Article: 79981
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Dr Justice" <sorry@no.spam.wanted>
Date: Mon, 28 Feb 2005 00:43:10 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: nospam <nospam@nospam.invalid>
Date: Mon, 28 Feb 2005 00:20:01 +0000
Links: << >>  << T >>  << A >>
"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
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx
From: Jeremy Stringer <jeremy@_NOSPAM_endace.com>
Date: Mon, 28 Feb 2005 13:30:45 +1300
Links: << >>  << T >>  << A >>
>>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,
Jeremy

Article: 79984
Subject: Re: I2C protocol to communicate between FPGAs
From: "Anthony Fremont" <spam@anywhere.com>
Date: Mon, 28 Feb 2005 00:44:54 GMT
Links: << >>  << T >>  << A >>

"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 IC interface on a chip (IC,
ASIC, FPGA, etc). It is Philips's position that all chips that can talk
to the IC 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 IC -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
Subject: Re: Prescalable counter
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 28 Feb 2005 13:59:27 +1300
Links: << >>  << T >>  << A >>
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).

-jg


Article: 79986
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Dr Justice" <sorry@no.spam.wanted>
Date: Mon, 28 Feb 2005 02:09:07 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: nospam <nospam@nospam.invalid>
Date: Mon, 28 Feb 2005 01:52:58 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: I2C protocol to communicate between FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Mon, 28 Feb 2005 02:21:28 GMT
Links: << >>  << T >>  << A >>
"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 IC 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
Subject: Re: Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Feb 2005 18:22:17 -0800
Links: << >>  << T >>  << A >>
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 Alfke


Article: 79990
Subject: Re: I2C protocol to communicate between FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 28 Feb 2005 16:16:28 +1300
Links: << >>  << T >>  << A >>
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 IC interface on a chip (IC,
> ASIC, FPGA, etc). It is Philips's position that all chips that can talk
> to the IC 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 IC -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


-jg


Article: 79991
Subject: Re: Maximum Current utilized by Spartan-3
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 27 Feb 2005 22:07:24 -0600
Links: << >>  << T >>  << A >>
>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
Subject: Quartus 4.2 SP1 woes with Samba & !@#$ "Flex"LM
From: Tommy Thorn <foobar@nowhere.void>
Date: Mon, 28 Feb 2005 05:29:36 GMT
Links: << >>  << T >>  << A >>
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,
Tommy

Article: 79993
Subject: Re: Quartus 4.2 SP1 woes with Samba & !@#$ "Flex"LM
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sun, 27 Feb 2005 22:36:59 -0800
Links: << >>  << T >>  << A >>
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: 79994
Subject: Re: spartan 3 vs virtex 2
From: digari@dacafe.com
Date: 27 Feb 2005 22:55:26 -0800
Links: << >>  << T >>  << A >>
So 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
Subject: Problem with LXT970A
From: Eug@newmail.ru (Eug)
Date: 28 Feb 2005 00:11:21 -0800
Links: << >>  << T >>  << A >>
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 Reagent

Article: 79996
Subject: Update EDK 6.1 to EDK 6.3
From: "Linas Petras" <lpetras@netspace.net.au.NOSPAM>
Date: Mon, 28 Feb 2005 19:49:25 +1100
Links: << >>  << T >>  << A >>
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

Linas



Article: 79997
Subject: Re: Prescalable counter
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 28 Feb 2005 09:50:13 +0100
Links: << >>  << T >>  << A >>
Preben Holm wrote:
> Gran 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.

Gran

<<<<< 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: 79998
Subject: Re: Implementing Multi-Processor Systems in FPGAs
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 28 Feb 2005 09:56:32 +0100
Links: << >>  << T >>  << A >>
Seems 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.

Gran 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
Subject: Re: spartan 3 vs virtex 2
From: "Benjamin Menkc" <benjamin@menkuec.de>
Date: Mon, 28 Feb 2005 10:01:38 +0100
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search