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 106350

Article: 106350
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 12 Aug 2006 12:52:03 +0200
Links: << >>  << T >>  << A >>
>> The last days I played around with the Quartus SOPC builder [1].
>> Although I'm more a batch/make guy, I'm impressed by the easy to use
>> tool. In order to scratch a little bit on the dominance of the NIOS II
>> in the SOPC world I wrapped JOP [2] into an Avalon component ;-)
>
> Kudos, that is excellent. Any lessons/gotchas about turning JOP into an
> SOPC components should someone else fancy a similar undertaking?

The Avalon bus is very flexible. Therefore, writing a slave or
master (SOPC component) is not that hard. The magic is in the Avalon
switch fabric generated by the builder. However, an example would
have helped (Altera listening?). I didn't find anything on Altera's
website or with Google. Now a very simple slave can be found at [1].

One thing to take care: When you (like me) like to avoid VHDL files
in the Quartus directory you can easily end up with three copies of
your design files. Can get confusing which one to edit. When you
edit your VHDL file in the component directory (the source for the
SOPC builder) don't forget to rebuild your system. The build process
copies it to your Quartus project directory.

When you want to start over with a clean project the only files
needed for the project are: .qpf, .qsf, .ptf

The master is also ease: just address, read and write data,
read/write and you have to react to waitrequest. See as example the
SimpCon/Avalon bridge at [2]. The Avalon interconnect fabric handles
all bus multiplexing, bus resizing, and control signal translation.

>> However, of course there is some drawback. The performance of the
>> Avalon system is lower than a 'native' connection (or in my case
>> via SimpCon [5]) of the main memory to the CPU. I can provide some
>> numbers if there is interest...
>
> Care to elaborate? I'd expect going over Avalon could add latency, but
> if you can exploit multiple outstanding transactions (aka "posted
> reads") and/or bust transfers, the bandwidth should be the same as
> "native".

Yes, the latency is the issue for JOP. JOP does not trigger several
read or write transactions. However, it can trigger one transaction
and than continue to execute microcode. When the (read) result is
needed, the JOP pipeline is stopped till the result is available.
What helps is to know in advance (one or two cycles) when the result
will be available. That's the trick with the SimpCon interface.
There is not a single ack or waitrequest signal, but a counter that
will say how many cycles it will take to provide the result. In this
case I can restart the pipeline earlier.

Another point is, in my opinion, the wrong role who has to hold data
for more than one cycle. This is true for several busses (e.g. also
Wishbone). For these busses the master has to hold address and write
data till the slave is ready. This is a result from the backplane
bus thinking. In an SoC the slave can easily register those signals
when needed longer and the master can continue. On the other hand,
as JOP continues to execute and it is not so clear when the result
is read, the slave should hold the data when available. That is easy
to implement, but Wishbone and Avalon specify just a single cycle
data valid.

>> BTW: The Cyclone II FPGA cannot be clocked really faster than the
>> Cyclone (just a few %). I hoped to get some speed-up for free due
>> to a new generation FPGA :-(
>
> I was surprised too when I saw that. I gather the only way the Cyclone
> II can gain you speed over Cyclone I is when you can use the embedded
> multipliers. Makes me wonder about the upcoming Cyclone III.

Are there any other data available on that. I did not find many
comments in this group on experiences with Cyclone I and II. Looks
like the CII was more optimized for cost than speed. Yes, waiting
for III ;-)

Martin

[1] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/sopc/components/avalon_test_slave/hdl/avalon_test_slave.vhd

[2] http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhd



Article: 106351
Subject: Re: JOP as SOPC component
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 12 Aug 2006 13:03:30 +0200
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:44ddb2d4$0$8024$3b214f66@tunews.univie.ac.at...
>>> The last days I played around with the Quartus SOPC builder [1].
>>> Although I'm more a batch/make guy, I'm impressed by the easy to use
>>> tool. In order to scratch a little bit on the dominance of the NIOS II
>>> in the SOPC world I wrapped JOP [2] into an Avalon component ;-)
>>
>> Kudos, that is excellent. Any lessons/gotchas about turning JOP into an
>> SOPC components should someone else fancy a similar undertaking?
>
> The Avalon bus is very flexible. Therefore, writing a slave or
> master (SOPC component) is not that hard. The magic is in the Avalon
> switch fabric generated by the builder. However, an example would
> have helped (Altera listening?). I didn't find anything on Altera's
> website or with Google. Now a very simple slave can be found at [1].
>
> One thing to take care: When you (like me) like to avoid VHDL files
> in the Quartus directory you can easily end up with three copies of
> your design files. Can get confusing which one to edit. When you
> edit your VHDL file in the component directory (the source for the
> SOPC builder) don't forget to rebuild your system. The build process
> copies it to your Quartus project directory.

Hi Martin,

most of the SOPC magin happens in the perl package "Europe" ASFAIK.
dont expect a lot of information about the internals of the package.

as very simple example for avalon master-slave type of peripherals there
is on free avalon IP core for SD-card support the core can be found
at some russian forum and later it was also added to the user ip
section of the microtronix forums.

the avalon master is really as simple as the slave.

Antti



Article: 106352
Subject: Re: Embedded clocks
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 12 Aug 2006 04:12:43 -0700
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On 11 Aug 2006 14:16:19 -0700, rickman
>  <spamgoeshere4@yahoo.com> wrote:
>
>
> >Thanks to everyone for their posts.  Each of the above solutions
> >require timing of the signal and so will not work without a clock (or
> >timer) of a specified rate.
>
> I'm not sure I understand this.
>
> Give me an oscillogram of a Manchester-coded signal and I can
> tell you its clock rate by inspection -  unless the data stream
> is all-1s or all-0s, and that's a corner case that we easily
> know how to avoid.  I need only one different bit in the
> entire oscillogram and I can work out what's going on with
> no _a priori_ knowledge of the data rate.

Actually, that is not correct.  Here are two sequences sampled at 1
MHz.  Please tell me the clock rates.

0101010101010101
0011001100110011

But I acknowledged that you could "measure" the data rate as long as
the bit stream allows for that.


> To achieve this I need only two things: (a) some means to
> measure the time between transitions, to a good enough
> precision; (b) enough memory to remember what's going
> on until I see a bit transition from 0 to 1 or back.  Condition
> (a) means, in  digital-land, some kind of oversampling and
> so it implies a *minimum* sampling clock rate; but
> measurement of edge-to-edge times imposes no lower
> limit on the data rate.
>
> I suspect rickman is looking for a scheme in which the
> data line can provide its own clock using some method
> other than oversampling.  Pulse-position or pulse-width
> modulation does that well enough, as do a whole raft
> of PSK techniques, but all of them require some kind
> of phase-locked loop or related means to act as a
> "flywheel" so that you can detect deviations of the
> line signal from an average clock that's also delivered
> by the line.

Pulse position and pulse with modulation still require a time
measurement which requires me to have a time reference on the receiver.


> Once you've introduced a PLL you are, of course, in
> something like analogue territory; and once you're
> there, a whole world of modulation techniques opens up.
> Amplitude-shift keying sounds about as self-clocking
> as it gets; there are ternary codes (positive-going pulse
> for 1, negative-going to 0), .......  And in the absence of
> any interfering signals these schemes are, trivially,
> self-timed.  Of course, as soon as you have other
> signals present on the same line, the obvious way
> to sort out one from another is by prior knowledge
> of the clock frequency.  Ask the radio guys about
> that - they are probably likely to speak of a "carrier"
> rather than "clock", and they may talk about "tuning"
> to choose a given signal!

If I am going to require a time reference at the receiver the simplest
scheme I know of is just async serial data with a start and a stop bit.
 No point in using Manchester encoding if I am transferring the data
over a wire just a few inches long.


Article: 106353
Subject: Re: Embedded clocks
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 12 Aug 2006 04:48:31 -0700
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> rickman wrote:
>
> > Thanks to everyone for their posts.  Each of the above solutions
> > require timing of the signal and so will not work without a clock (or
> > timer) of a specified rate.
>
> With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and
> 1. Should be easy to generate with an op-amp and to detect with another
> one. But I think it is easier to use a clock and normal digital signals.

The problem is lack of pins.  We are looking at a situation where we
don't want to make a connector any larger.  We need to multiplex two
separate bidirectional serial data streams and four discrete signals
over four or less pins.  I was thinking about ways of doing this and
realized that I had to provide a clock in the decoder.  So I either
have to use a pin or I have to add an oscillator to the decoder.  Since
the decoder will be in a cable, I need to keep it minimal.

Actually, decoder is a misnomer since it will have to both send and
receive.  So I don't see any way to get around the need for a timing
reference, either on a pin or by supplying an oscillator.  Most likely
it will be on a pin.  Right now I like the idea of using I2C, but I
will need to perform a detailed analysis of the tradeoffs vs. standard
async with separate clock, I2C, SPI and Manchester encoding.  I see
there are some very small packages for CPLDs, but they don't have much
logic in them.  I don't know if I can design such a transceiver in 64
logic cells.


Article: 106354
Subject: Re: Clock domain crossing (again)
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 12 Aug 2006 05:00:50 -0700
Links: << >>  << T >>  << A >>
jai.dhar@gmail.com wrote:
> Hey guys,
>
>  I'm having trouble getting started with my first clock-domain crossing
> task. I need to take in 2 signals; a 2.048M clock and associated data
> stream, and transfer it to a 50M stream that outputs a single-pulse
> clock and the captured data. What structure/resources can I use for
> this?

With a 50 MHz reference clock and adequate setup/hold times, you should
be able to do the entire design in that domain and never use the 2 MHz
clock as a true clock inside the FPGA.  First, all signals will need to
be clocked through two FFs to minimize metastability.  Unfortunately
this adds a 50 MHz clock period of jitter to any relative measurement.
With a 25:1 clock rate difference this should not be too much of a
concern, but keep it in mind as you perform a timing analysis.

Once all signals are sampled into the chip's clock domain you can do a
simple edge detection on the incoming 2.048 MHz clock signal to
generate a single 50 MHz clock wide, 2.048 MHz enable signal.  This
will be delayed or the data will be delayed by 50 MHz clock intervals
to put your sampling point in the center of your data setup and hold
period if it is at all critical.

After that you just use the 2.048 MHz enable signal to gate the
handling of the data.


Article: 106355
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Sat, 12 Aug 2006 14:10:23 +0200
Links: << >>  << T >>  << A >>
Hi Antti,

> most of the SOPC magin happens in the perl package "Europe" ASFAIK.
> dont expect a lot of information about the internals of the package.

That's fine for me. When the connection magic happens and I don't
have to care it's fine. OK, one exception: Perhaps I would like
to know more details on the latency. The switch fabric is 'plain'
VHdL or Verilog. However, generated code is very hard to read.

> as very simple example for avalon master-slave type of peripherals there
> is on free avalon IP core for SD-card support the core can be found
> at some russian forum and later it was also added to the user ip
> section of the microtronix forums.

Any link handy for this example?

> the avalon master is really as simple as the slave.

Almost, you have to hold address, data and read/write active
as long as waitrequest is pending. I don't like this, see above.

In my case e.g. the address from JOP (= top of stack) is valid
only for a single cycle. To avoid one more cycle latency I present
in the first cycle the TOS and register it. For additional wait
cycles a MUX switches from TOS to the address register. I know
this is a slight violation of the Avalon specification. There
can be some glitches on the MUX switch. For synchronous on-chip
peripherals this is absolute not issue. However, this signals
are also used for off-chip asynchronous peripherals (SRAM).
However, I assume that this possible switching glitches are
not really seen on the output pins (or at the SRAM input).

Martin



Article: 106356
Subject: Re: Embedded clocks
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 12 Aug 2006 14:24:50 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> Is self clocking on a single pin possible?

What about a synchronisation pulse or word at the begin of every 
transmission? The fast clock sources a counter, that has to be active, 
while  synchronisation pulse / word is been received. (In other words: 
The length of the sync pulse / word is measured - the reference time 
interval.) After this you know (with some error) the frequency of the 
incoming data stream.

All you need is a short time stable (long time unstable) oscillator (RC 
oscillator). For every transmission a new sync pulse / word is needed.

This kind of sync pulse / word is used for RFID transmission from 
interrogator to tag.


With a manchester encoded data stream it is furthermore possible to stay 
synchronized. During reception the sync machine may work too and if a 
data symbol is received that has equal length to the reference time 
interval the new measured length of this symbol may be used as new 
(re-synchronized) reference time interval.


The disadvantage: You need a fast clock - fast enough for even your 
highest data rates.

Ralf

Article: 106357
Subject: Re: ISE Webpack 8.1 adder wierdness
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 12 Aug 2006 14:37:40 +0200
Links: << >>  << T >>  << A >>
Todd Fleming wrote:

> The first two examples produce 16 4-input LUTs on a Spartan 3 and the
> third produces only 8 4-input LUTs.  Is there a way to get ISE to use
> only 8 LUTs without adding flipflops or resorting to a structural
> (XORCY, MUXCY, etc.) description?

> module adder_test_8_luts(clk, a, b, c, result);
>     input clk;
>     input[7:0] a, b;
>     input c;
>     output[8:0] result;
> 
>     reg[8:0] inv_b;
>     always @(posedge clk) inv_b <= ~b;
>     
>     assign result = a + inv_b + c;
> endmodule

I strongly guess that the flipflop has normal and inverted output. 
Therefore you get the inversion for free (for the cost of these flipflops).
And furthermore it seems to be, that the pure combinational solutions 
are slightly to complex to fit into 8 LUTs (the inversion is too much to 
fit).

Ralf

Article: 106358
Subject: Re: Clock domain crossing (again)
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 12 Aug 2006 05:38:18 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> jai.dhar@gmail.com wrote:
> > Hey guys,
> >
> >  I'm having trouble getting started with my first clock-domain crossing
> > task. I need to take in 2 signals; a 2.048M clock and associated data
> > stream, and transfer it to a 50M stream that outputs a single-pulse
> > clock and the captured data. What structure/resources can I use for
> > this?
>
> With a 50 MHz reference clock and adequate setup/hold times, you should
> be able to do the entire design in that domain and never use the 2 MHz
> clock as a true clock inside the FPGA.  First, all signals will need to
> be clocked through two FFs to minimize metastability.  Unfortunately
> this adds a 50 MHz clock period of jitter to any relative measurement.
> With a 25:1 clock rate difference this should not be too much of a
> concern, but keep it in mind as you perform a timing analysis.
>
> Once all signals are sampled into the chip's clock domain you can do a
> simple edge detection on the incoming 2.048 MHz clock signal to
> generate a single 50 MHz clock wide, 2.048 MHz enable signal.  This
> will be delayed or the data will be delayed by 50 MHz clock intervals
> to put your sampling point in the center of your data setup and hold
> period if it is at all critical.
>
> After that you just use the 2.048 MHz enable signal to gate the
> handling of the data.

The task isn't that clear, but a 2.048MHz clock makes me suspect there
is a serial data stream clocked at 2.048MHz that then is to be retimed
onto a 50MHz clock. In this case, there are a number of solutions, but
a more definitive statement is required. 2.048MHz is, of course, a very
common clock in PCM type applications as used in voice processing.

I *think* the OP is asking how to retime (maintaining the framing) a
serial data stream from one clock domain to another.

Cheers

PeteS


Article: 106359
Subject: Re: Compiler can't detect std_logic_1164 package
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 12 Aug 2006 05:41:24 -0700
Links: << >>  << T >>  << A >>
aijazbaig1@gmail.com wrote:

> First of all, you removed the line where I associated the component
> muxc with the entity mux. Inspite of that it worked. Is it because your
> component and entity name were the same? Is this a kind of a rule
> wherein if the names of the component and the entity are the same then
> we need not explicitly link the entity with the given component?

Yes, the default binding rule, but I find
this as confusing as you did.

I prefer to eliminate the component completely
and instance work.mux directly, like this:

architecture testbench of tb_mux is
signal a,b,c : std_logic_vector(7 downto 0);
signal sel  : std_logic_vector(1 downto 0);
  begin
  M1: entity work.mux
     port map (a   => a,         -- IN
               b   => b,         -- IN
               sel => sel,       -- IN
               c   => c);        -- OUT

> Secondly when we use the port map clause the arguments are actually
> passed and substituted position-wise in the component right?

Yes, that works, but I like the full mapping as above.
Renaming the signal identifiers as  a_s etc. is clearer still:

     port map (a   => a_s,         -- IN
               b   => b_s,         -- IN
               sel => sel_s,       -- IN
               c   => c_s);        -- OUT

  -- Mike Treseler

Article: 106360
Subject: Re: Embedded clocks
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 12 Aug 2006 14:51:13 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> If I am going to require a time reference at the receiver the simplest
> scheme I know of is just async serial data with a start and a stop bit.
>  No point in using Manchester encoding if I am transferring the data
> over a wire just a few inches long.

A serial data protocol like RS232 needs exact timing on sender and receiver
side. With the 1-wire protocol you need only one exact clock from the
master, the slave can use inexpensive RC components for timing and clock.

I've just implemented a VHDL program for reading the unique id of the
DS2432, which sits on my Spartan 3E starter kit. Some real-time logic
analyzer data:

http://www.frank-buss.de/tmp/1wire.png

As you can see, the timing precision of the device can varying by nearly a
factor of 2 and it would be still possible to communicate with it.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106361
Subject: Re: Embedded clocks
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 12 Aug 2006 15:02:08 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> Actually, decoder is a misnomer since it will have to both send and
> receive.  So I don't see any way to get around the need for a timing
> reference, either on a pin or by supplying an oscillator.  Most likely
> it will be on a pin.  Right now I like the idea of using I2C, but I
> will need to perform a detailed analysis of the tradeoffs vs. standard
> async with separate clock, I2C, SPI and Manchester encoding.  I see
> there are some very small packages for CPLDs, but they don't have much
> logic in them.  I don't know if I can design such a transceiver in 64
> logic cells.

Maybe you could use a microcontroller, like the MC9S08 from Freescale,
which I've used in a project: It is inexpensive, has A/D converters
integrated, so you don't need to use extra analog pins for the discrete
signals, I2C is implemented in hardware on the controller and it is about
1cm^2 wide, so it should fit in a cable (no other external components are
required, because it has lots of flash integrated and can generate the
system clock internally, if you don't need crystal precision). Then the
four pins of the cable would be: Vdd, Vcc, I2C data, I2C clock.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106362
Subject: Re: Embedded clocks
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 12 Aug 2006 14:15:37 +0100
Links: << >>  << T >>  << A >>
On 12 Aug 2006 04:12:43 -0700, rickman
 <spamgoeshere4@yahoo.com> wrote:

>Actually, that is not correct.  Here are two sequences sampled at 1
>MHz.  Please tell me the clock rates.
>
>0101010101010101
>0011001100110011

I can't because (a) I don't know whether the data stream is too
fast for me to measure with 1MHz, and (b) assuming there is no
aliasing going on, both streams have no data transitions in them.
I carefully pointed out in my post the need for (a) sufficiently
fast sampling, and (b) a variety of bits in the data stream.

>But I acknowledged that you could "measure" the data rate as long as
>the bit stream allows for that.

And surely, if I can measure it, I can then demodulate it?

[...]

>Pulse position and pulse with modulation still require a time
>measurement which requires me to have a time reference on the receiver.

I don't really know what you mean by "a time reference".  My point
about measurement is that you can demodulate ANY data rate up to
some upper limit determined by the time resolution of your receiver,
however that may be determined.  (There was an interesting discussion
about the relationship between that limit and the resolution - is the
maximum data rate 1/3 or 1/4 of your clock rate??? - but that doesn't
affect my argument.)  You don't need any prior knowledge of the
data rate whatsoever, except to be sure that it's slower than your
upper limit.

>If I am going to require a time reference at the receiver the simplest
>scheme I know of is just async serial data with a start and a stop bit.
> No point in using Manchester encoding if I am transferring the data
>over a wire just a few inches long.

Do I infer that you're looking for a scheme in which the clock can
be extracted with NO timing components at all in the receiver, i.e.
by combinational decoding of the data line?  If so, I'm pretty sure
it can't be done with any 2-level line discipline; but as soon as you
permit 3-level signalling, I think it's possible.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 106363
Subject: Re: Embedded clocks
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 12 Aug 2006 15:26:11 +0200
Links: << >>  << T >>  << A >>
Frank Buss wrote:

> http://www.frank-buss.de/tmp/1wire.png

I've added it, with some more explanation, to the Wikipedia page:

http://en.wikipedia.org/wiki/1-Wire

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106364
Subject: Re: Switching two (synchronous) clocks with variable phase difference,
From: David Tweed <dtweed@acm.org>
Date: Sat, 12 Aug 2006 13:36:11 GMT
Links: << >>  << T >>  << A >>
PeterC wrote:
> I have two clocks which are relatively synchronous (ie. the
 > frequencies are exactly the same because the originate from
 > the same master clock), but one of the clocks is shifted in
 > phase, and this phase shift is dynamically variable and may
 > be up to one whole period.
 >
 > I need to switch between these two clocks, but without losing
 > rising edges.

In that case, it's impossible, because two edges from the two
clocks can be arbitrarily close together.

Like other respondents, I too have done telecom applications
that needed hitless switching between streams that are
frequency-locked but not phase-locked. The answer involves
passing at least one of the clock+data streams through an
elastic buffer in order to realign their phase before trying
to do the switching. A 3-bit elastic buffer will allow just
shy of 2 unit intervals of peak-to-peak wander before causing
a hit.

If this is the sort of thing you need, I can dig up an
implementation for such a buffer that requires about 7
flip-flops and a handful of gates.

-- Dave Tweed

Article: 106365
Subject: Xilinx V4FX Embedded MAC.
From: Marc Kelly <marc@achenar.eclipse.co.uk>
Date: Sat, 12 Aug 2006 14:46:22 +0100
Links: << >>  << T >>  << A >>
Hi,

I was wondering if someone who has used the embedded MAC's can give me a
pointer here. I am using BaseX mode, with RocketIO to interface to a a
fibre SFP module then via fibre to a syskonnect card in a PC.

I have finally got my rocketIO working, after a lot of messing around
with all the settings and everything is working, or so it seems. However
I am having trouble getting the MAC to auto-negotiate. The PC on the end
of the fibre is sending the negotiation frames, and I have a little
embedded controller that is poking the MAC host interface configuration
registers to set stuff like the MDIO clock divider and such like. Once
that register is poked with a sane value I can see the MAC's tx data
also switch from sending idle frames to sending negotiation frames and a
few clocks later the CLIENTANINTERRUPT signal goes high. At this point I
assume they have negotiated? Or am i being silly?

But how do you then switch to normal data mode? (The PC at the other end
also stays in auto-negotiation mode too) Do I have to read/poke one of
the registers in the host interface or MDIO interface?

Anyone offer any hits with using these things?

Cheers..

BTW The code is based on the v4.1 wrapper, with the patches mentioned in
the various xilinx online docs.

-- 
/\/\arc Kelly
..Just your average physicist trying to get by in a world full of normal
people...

Article: 106366
Subject: Re: Compiler can't detect std_logic_1164 package
From: aijazbaig1@gmail.com
Date: 12 Aug 2006 07:01:53 -0700
Links: << >>  << T >>  << A >>
Hello Mike.
Thnks for letting me know that there are some people like myself who
prefer clarity and simplicity.
I know that VHDL - 93 allows one to completely do away  with components
but incase of VHDL - 87 , are we allowed to reference an entity
directly as you did. So what would M1 be in such a case as you did.
Normally M1 can be called an instant of the component in the "normal"
case when we instantiate components but now as you haven't declared any
components then what does M1 stand for. As far as I know we cannot have
instances of entities (or can we??). Its getting a lil confusing here.
would you kindly elaborate.

Secondly with regards to using the full mapping, do we have to place
the target signals on the right hand side of the "=>" operator inside
the port map clause brackets? Does this matter at all?

Hoping to hear from you soon,

Best Regards,
Aijaz Baig.
Mike Treseler wrote:
> aijazbaig1@gmail.com wrote:
>
> > First of all, you removed the line where I associated the component
> > muxc with the entity mux. Inspite of that it worked. Is it because your
> > component and entity name were the same? Is this a kind of a rule
> > wherein if the names of the component and the entity are the same then
> > we need not explicitly link the entity with the given component?
>
> Yes, the default binding rule, but I find
> this as confusing as you did.
>
> I prefer to eliminate the component completely
> and instance work.mux directly, like this:
>
> architecture testbench of tb_mux is
> signal a,b,c : std_logic_vector(7 downto 0);
> signal sel  : std_logic_vector(1 downto 0);
>   begin
>   M1: entity work.mux
>      port map (a   => a,         -- IN
>                b   => b,         -- IN
>                sel => sel,       -- IN
>                c   => c);        -- OUT
>
> > Secondly when we use the port map clause the arguments are actually
> > passed and substituted position-wise in the component right?
>
> Yes, that works, but I like the full mapping as above.
> Renaming the signal identifiers as  a_s etc. is clearer still:
>
>      port map (a   => a_s,         -- IN
>                b   => b_s,         -- IN
>                sel => sel_s,       -- IN
>                c   => c_s);        -- OUT
> 
>   -- Mike Treseler


Article: 106367
Subject: Re: JOP as SOPC component
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 12 Aug 2006 16:09:25 +0200
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:44ddc530$0$11352$3b214f66@tunews.univie.ac.at...
> Hi Antti,
>
>> most of the SOPC magin happens in the perl package "Europe" ASFAIK.
>> dont expect a lot of information about the internals of the package.
>
> That's fine for me. When the connection magic happens and I don't
> have to care it's fine. OK, one exception: Perhaps I would like
> to know more details on the latency. The switch fabric is 'plain'
> VHdL or Verilog. However, generated code is very hard to read.
>
>> as very simple example for avalon master-slave type of peripherals there
>> is on free avalon IP core for SD-card support the core can be found
>> at some russian forum and later it was also added to the user ip
>> section of the microtronix forums.
>
> Any link handy for this example?
>
http://forum.niosforum.com/forum/index.php?showtopic=4430

antti



Article: 106368
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 12 Aug 2006 07:19:46 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> You may not notice but I did decode exactly what you show BUT I included the
> preceeding and following bits as well.  The inversion is the issue.  Some
> references suggest the bit value is in the first half, some the second.
> This is pointed out later in the wikipedia article.  I used the first half
> of the bit period for the data but you can see my bit half pairs are
> correct.

First let me say that I am not trying to be rude in any way.  If you
read my posts and see something that you find offensive, I did not
intend that.  My comment below about reviewing Wikipedia was meant as a
simple statement, not an insult.  So I apologize for anything that is
perceived as offensive.  Please keep in mind that writing is very
different from speaking.  Since tone can not be conveyed redily words
can be interpreted very differently depending on the tone you perceive.


For the technical issues... The inversion is not the relevant issue.
If you had an algorithm that would decode the stream I gave you as the
inverted data I would have accepted that.  The problem is the timing.
The way Manchester is decoded is to trigger a timer (it was a one shot
back when I first worked on this problem) that will ignore any
following transitions for approx 3/4 of a bit time.  This gives you
+-1/4 of a bit time to allow for distortion and jitter in the signal.
When you sample the incoming signal with a 3x clock or a 4x clock there
are degenerate cases where the signal is sampled at the time it is
changing which adds a full clock period to the jitter.  In both of
these cases there is not enough margin to allow for this an you can get
erroneous decoding.

Your analysis, if I understood it correctly, produced 6 bits of data
when there were only four.  I am also interested in the algorithm you
used.  It would be instructive if you gave us the detail of how you
decode the bit stream.

Ok, I think I understand where the extra 2 bits came from.  Somehow you
assumed that the intial and final zeros were adjacent to ones and added
extra edges that produced data.  So we can ignore those edges and the
other data looks good.  But what was your algorithm?  You need to have
a method that can be implemented in logic.  I am pretty confident that
no matter what algorithm you choose, I can find a case where it won't
work.


> Of COURSE the sampling doesn't produce an evenly PACED distribution of
> pulses, it produces counts of 2 to 4 for the two half bits from adjecent
> values and counts from 1-2 for the isolated half bits.  It happens that
> these overlap as I described.  If you only have an all-zero or all-one
> pattern then no, you cannot ambiguously extract the data.  Once you get any
> other data, the alignment is guaranteed.

I think you are referring to the initial alignment.  Manchester
encoding is typically used in systems where the signal is broadcast
over a radio or other analog medium which can have timing and amplitude
distortions which can introduce erroneous bits.  That is typically
handled by sending a synchrononization sequence of alternating 1s and
0s.  This produces a pattern of transitions only at the bit center to
assure proper alignment.  The sequences I sent did not include any
medium induced distortions, so the initial transition was a bit center
and was an appropriate transition to start your process.

> You mentioned the sequences need to be decoded to 1001 yet you decoded 1100.
> At the 2x transmit output, the encoded sequence would be either 10100101 or
> 01011010 depending on your polarity.  Is that what you were attempting to
> show?  Or was it 1100?

Yes, the second bitstream produces a wrong pattern because of the
jitter introduced.  That is my point.  You can decode the first
bitstream because there is no distortion.  But the second bitstream
shows that that distortion introduced by sampling on the transition
will give errors and can not be avoided with a 3x or 4x clocking
scheme.


> Your "go back to Wikipedia" comment was uncalled for.  If you don't
> understand what I'm trying to describe or vice-versa, it's a problem with
> the communication medium (to include the inaccuracies of English) and not
> that I'm brain challenged.

As I posted above, I was not trying to insult you.  I was suggesting
that you do not understand how to decode a Manchester encoded signal
and should check the references.  Sorry that it sounded like an insult.
 I have no reason to insult anyone here and I apologize.


> Embedded clocks are used all over.  Successfully.  But you don't see it.
> Are you right?

I don't understand what you are saying with this.


> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:1155329590.259386.229690@h48g2000cwc.googlegroups.com...
> > John_H wrote:
> >> "John_H" <newsgroup@johnhandwork.com> wrote in message
> >> news:Iu5Dg.7581$Oh1.4082@news01.roc.ny...
> >>
> >> >  0001101110010000
> >> > 10  01  01  10  10   01
> >> > 1   0    0     1    1    0
> >> >
> >> > 0000101111010000
> >> > 10   01 01  10  10  01
> >> > 1    0   0   1    1    0
> > Ok, that is what you are not getting.  Time sampling does not produce
> > an even distribution of pulses in the time sampled domain with a 3x
> > clock.  The above sequences both need to be decoded to the same
> > sequence, 1001.  The first sequence assumes "ideal" sampling with no
> > timing abiguities.  The second sequence is what you might get if the
> > sampling is done right on the important edges and a small amount of
> > jitter messes up your data.
> >
> > 000_1101110010000
> >     ^  First bit = 1
> > 00011_01110010000
> >        ^  edge between bits, ignore
> > 000110_1110010000
> >          ^  Second bit = 1
> > 000110111_0010000
> >               ^  Third bit = 0
> > 00011011100_10000
> >                   ^  edge between bits, ignore
> > 000110111001_0000
> >                     ^  Fourth bit = 0


Article: 106369
Subject: Re: Gaisler on a Spartan 3E Starter Kit?
From: "David M. Palmer" <dmpalmer@email.com>
Date: Sat, 12 Aug 2006 08:25:30 -0600
Links: << >>  << T >>  << A >>
In article <110820062235029049%dmpalmer@email.com>, David M. Palmer
<dmpalmer@email.com> wrote:

> Gaisler has a nice suite of GPL'd IP for an AMBA-bussed Leon3 (SPARC)
> system with Ethernet, DDR RAM, Spacewire, PCI, AES Crypto, and others. 
>  http://www.gaisler.com

Following up, I sent this question to Gaisler, and he said:

> The board uses a XC3S500 FPGA which about 10,000 cells.
> You will be able to fit a minimum leon3 system, but not
> much more. One problem is that the board uses 16-bit DDR
> memory, but the leon3/grlib DDR controller can only handle
> 32-bit memory banks.
> 
> Jiri.

So I may have to stick with OpenCores and/or whatever useful components
I can extract from the Gaisler cores.

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

Article: 106370
Subject: Re: Clock domain crossing (again)
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 12 Aug 2006 07:28:42 -0700
Links: << >>  << T >>  << A >>
PeteS wrote:
> rickman wrote:
> > jai.dhar@gmail.com wrote:
> > > Hey guys,
> > >
> > >  I'm having trouble getting started with my first clock-domain crossing
> > > task. I need to take in 2 signals; a 2.048M clock and associated data
> > > stream, and transfer it to a 50M stream that outputs a single-pulse
> > > clock and the captured data. What structure/resources can I use for
> > > this?
> >
> > With a 50 MHz reference clock and adequate setup/hold times, you should
> > be able to do the entire design in that domain and never use the 2 MHz
> > clock as a true clock inside the FPGA.  First, all signals will need to
> > be clocked through two FFs to minimize metastability.  Unfortunately
> > this adds a 50 MHz clock period of jitter to any relative measurement.
> > With a 25:1 clock rate difference this should not be too much of a
> > concern, but keep it in mind as you perform a timing analysis.
> >
> > Once all signals are sampled into the chip's clock domain you can do a
> > simple edge detection on the incoming 2.048 MHz clock signal to
> > generate a single 50 MHz clock wide, 2.048 MHz enable signal.  This
> > will be delayed or the data will be delayed by 50 MHz clock intervals
> > to put your sampling point in the center of your data setup and hold
> > period if it is at all critical.
> >
> > After that you just use the 2.048 MHz enable signal to gate the
> > handling of the data.
>
> The task isn't that clear, but a 2.048MHz clock makes me suspect there
> is a serial data stream clocked at 2.048MHz that then is to be retimed
> onto a 50MHz clock. In this case, there are a number of solutions, but
> a more definitive statement is required. 2.048MHz is, of course, a very
> common clock in PCM type applications as used in voice processing.
>
> I *think* the OP is asking how to retime (maintaining the framing) a
> serial data stream from one clock domain to another.

That was exactly what I assumed.  Regardless, my approach will do the
job in any case.  This is what we did in a telecom application I worked
on where the data rate varied over a wide range from T1 to OC48, but
the clock rate remained the same.  We maintained an internal bus width
at 32 bits but used a clock enable to allow a very wide range of data
rates.  Of course the input data and clock were synchronized in just
the way I described above.  If the serial data is being shifted into an
8 or 32 bit register you just gate the 2.048 MHz enable pulse to only
allow every Nth pulse through to produce a 2.048/N MHz enable signal.

This approach is very common and not at all hard to understand.


Article: 106371
Subject: Re: ISE Webpack 8.1 adder wierdness
From: "Todd Fleming" <tbfleming@gmail.com>
Date: 12 Aug 2006 08:07:04 -0700
Links: << >>  << T >>  << A >>
Sylvain Munaut wrote:
> Todd Fleming wrote:
> > module adder_test_16_luts_1(a, b, c, result);
> >     input[7:0] a, b;
> >     input c;
> >     output[8:0] result;
> >
> >     assign result = a + (~b) + c;
> > endmodule
>
> Have you tried with
>
> assign result = (~b) + a + c;
>
> ?
>
>
>     Sylvain

Oooh, good idea.  Trying it now...  Whoa! this one used 22!  For
reference, here is the 22-LUT version:

module adder_test_22_luts(a, b, c, result);
    input[7:0] a, b;
    input c;
    output[8:0] result;

    assign result = (~b) + a + c;
endmodule

Todd


Article: 106372
Subject: Re: Embedded clocks
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 12 Aug 2006 17:05:27 +0100
Links: << >>  << T >>  << A >>
On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>Frank Buss wrote:
>> rickman wrote:
>>
>> > Is self clocking on a single pin possible?  I am thinking that the
>> > extra info has to be presented in some manner that requires either a
>> > timing or amplitude measurement.
>>
>> As Jim wrote, the one-wire bus can do this. With this concept you need only
>> one wire (and ground) to power and communicate with a device:
>>
>> http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf
>> http://www.maxim-ic.com/appnotes.cfm/an_pk/126
>
>Thanks to everyone for their posts.  Each of the above solutions
>require timing of the signal and so will not work without a clock (or
>timer) of a specified rate.  The key is "specified".  To decode a
>machester stream you need a time interval of about 3/4 of the bit time
>in order to blank the edge detector on the edge between bits. 

If you *know* it's Manchester coding, and have *no idea* of the clock
rate, the problem can be solved if you can afford to spend some time
framing up. It's harder if you instantly need to decode the first bit.

Basic approach is to measure the times between transitions, compare
several successive transition intervals, and classify them as "long" or
"short" compared to each other. THEN take a mean value, apply blanking
(clock recovery), and start framing up. 

(If you need to retroactively decode the first bit, you'll need to store
and re-visit the first few transition times. This may be easier with the
assistance of an embedded CPU)

There will need to be some constraints on data, otherwise an infinite
sequence of '0's or '1's would take infinitely long to decode. In SP/DIF
or EBU/AES digital audio for example, this comes in the form of an
extra-long transition interval (1.5 bit times) during a preamble, the
trailing edge of which is guaranteed to correctly sync the clock
recovery circuit.


>So I can't read a Manchester stream at 10 Mbps and one at 1
>Mbps with the same timer. 

This approach should allow that - given some quiet time between
different streams, to enable you to recognise a switch in rate.

- Brian

Article: 106373
Subject: Re: Embedded clocks
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 12 Aug 2006 17:10:03 +0100
Links: << >>  << T >>  << A >>
On 12 Aug 2006 04:12:43 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>Jonathan Bromley wrote:
>> On 11 Aug 2006 14:16:19 -0700, rickman
>>  <spamgoeshere4@yahoo.com> wrote:
>>
>>
>> >Thanks to everyone for their posts.  Each of the above solutions
>> >require timing of the signal and so will not work without a clock (or
>> >timer) of a specified rate.
>>
>> I'm not sure I understand this.
>>
>> Give me an oscillogram of a Manchester-coded signal and I can
>> tell you its clock rate by inspection -  unless the data stream
>> is all-1s or all-0s, and that's a corner case that we easily
>> know how to avoid.  I need only one different bit in the
>> entire oscillogram and I can work out what's going on with
>> no _a priori_ knowledge of the data rate.
>
>Actually, that is not correct.  Here are two sequences sampled at 1
>MHz.  Please tell me the clock rates.
>
>0101010101010101
>0011001100110011

Where are the "different" bits specified by Jonathan in that sequence?
These are both sequences of *identical* bits - all 1's or all 0's (when
stripped of their clock), which Johnathan already covered.

- Brian


Article: 106374
Subject: Re: EDK: OPB_IPIF, too many versions...
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 12 Aug 2006 17:25:28 +0100
Links: << >>  << T >>  << A >>
On Fri, 11 Aug 2006 18:27:48 -0400, "MM" <mbmsv@yahoo.com> wrote:

>Hi all,
>
>I have created a custom OPB peripheral template with the wizard and now
>trying to make sense of it... I noticed that the wizard included the
>opb_ipif_v2_00_h interface. However the EDK directory has all kinds of
>versions of the same interface up to v3_01_c... Can someone explain what are
>the differences between all of them and why the wizard picked one from the
>middle and not the latest?

One difference is that 3.01 supports autoincrement addressing, which can
be useful for DMA.

However, 3.01 is slave only, it does not offer bus mastering capability
with an internal DMA controller; that requires 2.xx.

This is unfortunate for me, having started with 3.01; I am currently
using "opb_central_dma" for DMA transfers. Which double-handles data
(reads it from external memory into its own buffer; THEN writes it to my
core in a separate operation, taking 2 cycles per word transferred, plus
overheads as it only transfers bursts of 16 words at a time. 

When I want to add keyhole DMA to my core (to transfer data in a single
operation) I will have to step back to 2.xx. 

Anyway my guess is that you asked for OPB bus mastering capability, and
the wizard picked the latest core that supports it...

Xilinx - what is the reasoning behind this? 
Where is it clearly explained?
Are there any plans for a 3.xx version WITH mastering and DMA support?

And why is the autoincrement addressing (burst mode) in 3.01 limited to
maximum 16 words per burst?

- Brian



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