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
2017JanFebMarApr2017

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 155575

Article: 155575
Subject: Re: Xilinx ISE GUI vs tcl script problem
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 23 Jul 2013 10:06:17 -0400
Links: << >>  << T >>  << A >>
nmatringe@gmail.com wrote:
> Hello
> I've used tcl scripts for quite a long time now and been very happy until yesterday when suddenly the script interpreter started picking the wrong top level unit.
> So I have a perfectly compiling design in the GUI, I generate a tcl script and when I run it (xtclsh myscript.tcl) it stops with an error message, and when I look at the log I can see it has used "blkmem.xco" as top level unit.
> Does anyone know what's going on in there ?
> 
> Thanks
> Nicolas

Is it possible that you had "blkmem.xco" selected in the hierarchy view
at the time you generated the script?  I know a lot of the commands are
sensitive to the current selection.

-- 
Gabor

Article: 155576
Subject: Nios II problem with DDR core SOPC builder
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Tue, 23 Jul 2013 07:25:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello all:

I am currently transitioning a Quartus 8.0 (subscription edition) project to Quartus 12.1 (web edition).

I am facing couple of problems:
1. The NIOS II Eclipse tool does not run the code correctly. I see the following error:
Pausing target processor: not responding
Resetting and trying again: FAILED
Leaving target processor paused

I searched for this error and saw a lot of replies talking about generating the BSP using the BSP editor and not the context menu in Eclipse. I tried both methods and this problem is not resolved.
One thing I have observed is that when I create a Hello_world_small project from scratch, it runs on NiosII. Once I start adding my code or modify the file to start using system.h the project does not run on NiosII and I see the error above.

2. In my SOPC builder I am using the DDR2 module and I don't know if this core requires the subscription edition to work correctly.

Please advise if you have seen similar issues.

Thanks.

P.S: I have posted similar thread on the Altera forum as well http://www.alteraforum.com/forum/showthread.php?t=41581 (No replies there !)

Article: 155577
Subject: Re: Metastability mitigation and I/O registers
From: "RCIngham" <2161@embeddedrelated>
Date: Tue, 23 Jul 2013 10:01:58 -0500
Links: << >>  << T >>  << A >>
Well, as I couldn't work out how to specify the timing constraint(s) I
needed, I did some post-layout simulations instead. I split the bunch of
discretes into two, half with '-register yes' and the others with
'-register no' in the 'set_io' constraint, then swapped the constraints
over for a second build+simulate pass.

In both cases the arrival at the 'D' input of the second register was
slightly faster and slightly more consistent in the '-register yes' cases.
The time delta between groups was about 150ps, so it might be worth having.
And I now have a possibly accurate CK-to-D time to put in my Metastability
MTBF spreadsheet.

YMMV for other technologies.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155578
Subject: Re: Nios II problem with DDR core SOPC builder
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 23 Jul 2013 16:25:55 +0100 (BST)
Links: << >>  << T >>  << A >>
Vivek Menon <vivek.menon79@gmail.com> wrote:
> Hello all:
> 
> I am currently transitioning a Quartus 8.0 (subscription edition) project
> to Quartus 12.1 (web edition).

Are you using SOPC Builder or Qsys (probably better to bite the bullet and
port to Qsys at some point)?
 
> I am facing couple of problems:
> 1. The NIOS II Eclipse tool does not run the code correctly. I see the following error:
> Pausing target processor: not responding
> Resetting and trying again: FAILED
> Leaving target processor paused

That means your FPGA 'doesn't work'.  It means that Quartus couldn't talk to
the NIOS II in your design.  It could be any kind of problem, but often that
the clocks or resets are wrong (I think SOPC Builder inserted clocks/resets
automatically, which Qsys doesn't).

> 2. In my SOPC builder I am using the DDR2 module and I don't know if this
> core requires the subscription edition to work correctly.

I imagine you'd get a license error if so.  I've had trouble porting the
DDR2 controller into a newer Qsys version.  Try deleting it and re-adding
(using DDR2 UniPHY if possible).  Is your code in DDR2 or BRAM?  This could
be the cause of issue 1.  A basic test would be to put it in BRAM ('On Chip
Memory' Qsys component) to start with, so that you know the basic toolchain
works.

Theo

Article: 155579
Subject: FF Replication with Xilinx ISE
From: Leo <capossio.leonardo@gmail.com>
Date: Tue, 23 Jul 2013 09:05:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I have a design that needs to stall a long pipeline (with the CE input =
of registers). The module receiving data from this pipeline sends a busy si=
gnal, that within 3 clock cycles must completely stall the pipeline. The lo=
ng routing delays from the end to the beginning of the pipeline cause my de=
sign to fail timing.

Now, since the STALL signal comes from a shift register made of (3) Flip-Fl=
ops, how can I get the tool to replicate this flip-flop chain, i.e. make a =
flip flop tree in such a way that meets timing ?

I have tried putting a MAX_FANOUT constraint to the high fanout signal, but=
 the only thing this does is replicate the buffers. Also tried applying "Re=
gister Duplication" and "Register Re-Timing" to no-avail (the registers are=
n't duplicated, they are moved around a little only).

I want this done automatically because the pipeline can vary it's size, but=
 I don't know if it is practical anymore.

Article: 155580
Subject: Re: Nios II problem with DDR core SOPC builder
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Tue, 23 Jul 2013 13:16:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
1. I tried looking at Qsys and transitioning from SOPC to Qsys. Unfortunate=
ly only the clock and reset signals were instantiated as ports to this desi=
gn. I suspect some transition issue and left it at that.

2. The clocks and resets are being assigned by SOPC builder and I am not su=
re if the reset should be connected if it was not available as an option in=
 v8.0

ALso, I am using the Altera Cyclone III dev kit DK-DEV-3C120N=20

Thanks in advance.=20

On Tuesday, July 23, 2013 11:25:55 AM UTC-4, Theo Markettos wrote:
> Vivek Menon wrote: > Hello all: > > I am currently transitioning a Quartu=
s 8.0 (subscription edition) project > to Quartus 12.1 (web edition). Are y=
ou using SOPC Builder or Qsys (probably better to bite the bullet and port =
to Qsys at some point)? > I am facing couple of problems: > 1. The NIOS II =
Eclipse tool does not run the code correctly. I see the following error: > =
Pausing target processor: not responding > Resetting and trying again: FAIL=
ED > Leaving target processor paused That means your FPGA 'doesn't work'. I=
t means that Quartus couldn't talk to the NIOS II in your design. It could =
be any kind of problem, but often that the clocks or resets are wrong (I th=
ink SOPC Builder inserted clocks/resets automatically, which Qsys doesn't).=
 > 2. In my SOPC builder I am using the DDR2 module and I don't know if thi=
s > core requires the subscription edition to work correctly. I imagine you=
'd get a license error if so. I've had trouble porting the DDR2 controller =
into a newer Qsys version. Try deleting it and re-adding (using DDR2 UniPHY=
 if possible). Is your code in DDR2 or BRAM? This could be the cause of iss=
ue 1. A basic test would be to put it in BRAM ('On Chip Memory' Qsys compon=
ent) to start with, so that you know the basic toolchain works. Theo


Article: 155581
Subject: Re: FF Replication with Xilinx ISE
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 23 Jul 2013 16:38:10 -0400
Links: << >>  << T >>  << A >>
Leo wrote:
> Hi, I have a design that needs to stall a long pipeline (with the CE input of registers). The module receiving data from this pipeline sends a busy signal, that within 3 clock cycles must completely stall the pipeline. The long routing delays from the end to the beginning of the pipeline cause my design to fail timing.
> 
> Now, since the STALL signal comes from a shift register made of (3) Flip-Flops, how can I get the tool to replicate this flip-flop chain, i.e. make a flip flop tree in such a way that meets timing ?
> 
> I have tried putting a MAX_FANOUT constraint to the high fanout signal, but the only thing this does is replicate the buffers. Also tried applying "Register Duplication" and "Register Re-Timing" to no-avail (the registers aren't duplicated, they are moved around a little only).
> 
> I want this done automatically because the pipeline can vary it's size, but I don't know if it is practical anymore.

The last time I tried to play with this in the Xilinx tools, I found
that I had to both turn on register duplication, and turn off equivalent
register removal.  However, in the end I think even that didn't really
fix the timing and I ended up replicating the signal myself.  Again
that gets fun because XST really wants to remove redundant logic,
so I usually tricked it by using a staggered startup (different
delay of reset to each of the replicated flops), which didn't
really affect operation in my system because nothing was happening
right after configuration anyway.

-- 
Gabor

Article: 155582
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: Anssi Saari <as@sci.fi>
Date: Tue, 23 Jul 2013 23:44:35 +0300
Links: << >>  << T >>  << A >>
jg <j.m.granville@gmail.com> writes:

> On Thursday, July 18, 2013 11:44:37 PM UTC+12, Anssi Saari wrote:
>> BTW, apparently Altera is coming up with small FPGAs along the lines of
>> Lattice's MachXO2 line. It's funny how the XO2-1200 seems like a MaxII
>> EPM1270 with 10 more LEs, a PLL and some RAM...
>
>
> Any indications of when ?

I think it was 2014. I may have some notes somewhere but they were
pretty vague on everything.




Article: 155583
Subject: Re: Nios II problem with DDR core SOPC builder
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 24 Jul 2013 00:09:12 +0100 (BST)
Links: << >>  << T >>  << A >>
Vivek Menon <vivek.menon79@gmail.com> wrote:
> 1. I tried looking at Qsys and transitioning from SOPC to Qsys.
> Unfortunately only the clock and reset signals were instantiated as ports
> to this design.  I suspect some transition issue and left it at that.
> 
> 2. The clocks and resets are being assigned by SOPC builder and I am not
> sure if the reset should be connected if it was not available as an option
> in v8.0

TBH you're probably better recreating the design in Qsys and starting from
there.  There's far too many gotchas involved in porting old files to newer
versions that it's often just simplest to build it again, particularly if it
isn't a complex design.  DDR2 memory is often troublesome here - it builds,
but it doesn't work.

Q12.1 to Q13.0 seems to be better than previous versions in this respect. 
One tip, if you are porting forward (or back), is to load and resave your
.qsys file before trying to generate a system in the new version, otherwise
it tries to instantiate the old version and sometimes gets it wrong.

You'll have to explicitly wire clocks and resets but that's probably safer
than it guessing and getting it wrong.

Another tip: once your built your system in Quartus, go into the synthesis/
directory and there's a TCL script for assigning DDR2 pins.  You need to run
this from Quartus so that the attributes on the pins are set correctly (and
then rebuild), otherwise they won't have the right drivers on them.  You
only need to do this once.

Theo

Article: 155584
Subject: Re: FF Replication with Xilinx ISE
From: Leo <capossio.leonardo@gmail.com>
Date: Wed, 24 Jul 2013 04:46:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, July 23, 2013 5:38:10 PM UTC-3, Gabor wrote:
> Leo wrote:
>=20
> > Hi, I have a design that needs to stall a long pipeline (with the CE in=
put of registers). The module receiving data from this pipeline sends a bus=
y signal, that within 3 clock cycles must completely stall the pipeline. Th=
e long routing delays from the end to the beginning of the pipeline cause m=
y design to fail timing.
>=20
> >=20
>=20
> > Now, since the STALL signal comes from a shift register made of (3) Fli=
p-Flops, how can I get the tool to replicate this flip-flop chain, i.e. mak=
e a flip flop tree in such a way that meets timing ?
>=20
> >=20
>=20
> > I have tried putting a MAX_FANOUT constraint to the high fanout signal,=
 but the only thing this does is replicate the buffers. Also tried applying=
 "Register Duplication" and "Register Re-Timing" to no-avail (the registers=
 aren't duplicated, they are moved around a little only).
>=20
> >=20
>=20
> > I want this done automatically because the pipeline can vary it's size,=
 but I don't know if it is practical anymore.
>=20
>=20
>=20
> The last time I tried to play with this in the Xilinx tools, I found
>=20
> that I had to both turn on register duplication, and turn off equivalent
>=20
> register removal.  However, in the end I think even that didn't really
>=20
> fix the timing and I ended up replicating the signal myself.  Again
>=20
> that gets fun because XST really wants to remove redundant logic,
>=20
> so I usually tricked it by using a staggered startup (different
>=20
> delay of reset to each of the replicated flops), which didn't
>=20
> really affect operation in my system because nothing was happening
>=20
> right after configuration anyway.
>=20
>=20
>=20
> --=20
>=20
> Gabor

OK, now the problem would be how to do it dynamically. I mean, if the pipel=
ine gets bigger or there is more than one pipeline running in parallel, how=
 can I set the appropriate number of replicas of the signal (without trial-=
and-error)?

Article: 155585
Subject: Re: FF Replication with Xilinx ISE
From: rndhro <rnd@hro.net>
Date: Wed, 24 Jul 2013 16:13:47 +0200
Links: << >>  << T >>  << A >>

> OK, now the problem would be how to do it dynamically. I mean, if the pipeline gets bigger or there is more than one pipeline running in parallel, how can I set the appropriate number of replicas of the signal (without trial-and-error)?
>

I think the attributes "equivalent_register_removal" and "shreg_extract" 
(getting SRL16s doesn't help with timing...) could help you there. 
Replicate the registers 'by hand' in your pipeline entity and set the 
above attributes. By instantiating this module several times each 
instance will have it's own set of registers....
You can set the attributes in the VHDL code. Example:
attribute equivalent_register_removal : string;
attribute equivalent_register_removal of [signal_name] : signal is "no";

HTH

Article: 155586
Subject: Re: Nios II problem with DDR core SOPC builder
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Wed, 24 Jul 2013 07:38:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Mistake: I am using the DDR memory module with NiosII. DO you know if there=
's a tcl scriptfor assigning DDR pins.


On Tuesday, July 23, 2013 7:09:12 PM UTC-4, Theo Markettos wrote:
TBH you're probably better recreating the design in Qsys and starting from =
there. There's far too many gotchas involved in porting old files to newer =
versions that it's often just simplest to build it again, particularly if i=
t isn't a complex design. DDR2 memory is often troublesome here - it builds=
, but it doesn't work. Q12.1 to Q13.0 seems to be better than previous vers=
ions in this respect. One tip, if you are porting forward (or back), is to =
load and resave your .qsys file before trying to generate a system in the n=
ew version, otherwise it tries to instantiate the old version and sometimes=
 gets it wrong. You'll have to explicitly wire clocks and resets but that's=
 probably safer than it guessing and getting it wrong. Another tip: once yo=
ur built your system in Quartus, go into the synthesis/ directory and there=
's a TCL script for assigning DDR2 pins. You need to run this from Quartus =
so that the attributes on the pins are set correctly (and then rebuild), ot=
herwise they won't have the right drivers on them. You only need to do this=
 once. Theo


Article: 155587
Subject: Re: FF Replication with Xilinx ISE
From: Leo <capossio.leonardo@gmail.com>
Date: Wed, 24 Jul 2013 11:24:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 24, 2013 11:13:47 AM UTC-3, rndhro wrote:
> > OK, now the problem would be how to do it dynamically. I mean, if the p=
ipeline gets bigger or there is more than one pipeline running in parallel,=
 how can I set the appropriate number of replicas of the signal (without tr=
ial-and-error)?
>=20
> >
>=20
>=20
>=20
> I think the attributes "equivalent_register_removal" and "shreg_extract"=
=20
>=20
> (getting SRL16s doesn't help with timing...) could help you there.=20
>=20
> Replicate the registers 'by hand' in your pipeline entity and set the=20
>=20
> above attributes. By instantiating this module several times each=20
>=20
> instance will have it's own set of registers....
>=20
> You can set the attributes in the VHDL code. Example:
>=20
> attribute equivalent_register_removal : string;
>=20
> attribute equivalent_register_removal of [signal_name] : signal is "no";
>=20
>=20
>=20
> HTH

I have tried assigning attributes to signals/entities before. My question w=
ould be: If I have an entity (in VHDL or Module in Verilog) that has a Cloc=
k Enable (CE) input that goes to all the registers inside the entity, how c=
an I make the entity portable and generic enough (i.e. to be use it in a di=
fferent design), without needing to replicate the CE signal for each (large=
) set of registers (hence ending up with as many CE inputs as groups of reg=
isters are inside)?

Article: 155588
Subject: Re: Nios II problem with DDR core SOPC builder
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 24 Jul 2013 22:59:01 +0100 (BST)
Links: << >>  << T >>  << A >>
Vivek Menon <vivek.menon79@gmail.com> wrote:
> Mistake: I am using the DDR memory module with NiosII. DO you know if
> there's a tcl scriptfor assigning DDR pins.

If you're using the DDR controller with UniPHY, there probably is.  I never
looked for such a thing on the older AltMemPHY controller.

Theo

Article: 155589
Subject: Re: Nios II problem with DDR core SOPC builder
From: "scrts" <delete@myemail.com>
Date: Thu, 25 Jul 2013 08:52:48 +0300
Links: << >>  << T >>  << A >>
There's also for AltMemPHY.
Quartus: Tools -> TCL Scripts...


"Theo Markettos"  wrote in message 
news:jMd*jobFu@news.chiark.greenend.org.uk...

Vivek Menon <vivek.menon79@gmail.com> wrote:
> Mistake: I am using the DDR memory module with NiosII. DO you know if
> there's a tcl scriptfor assigning DDR pins.

If you're using the DDR controller with UniPHY, there probably is.  I never
looked for such a thing on the older AltMemPHY controller.

Theo 


Article: 155590
Subject: New Relay Computer
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Thu, 25 Jul 2013 15:07:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
I've made a new relay computer: check out http://relaysbc.sourceforge.net
(look for the videos on the example programs page).

This one is a single board computer, like the microprocessor trainers of the
70s and 80s.

A trick to keep the relay count very low is my design for a master-slave
flip-flop.  By using a capacitor for the master side and a holding resistor
based latch for the slave side, only 1.5 relays per bit are needed.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155591
Subject: Re: Xilinx "Ultrascale" announcement leaves out low-cost devices
From: rickman <gnuarm@gmail.com>
Date: Fri, 26 Jul 2013 03:57:18 -0400
Links: << >>  << T >>  << A >>
On 7/23/2013 4:44 PM, Anssi Saari wrote:
> jg<j.m.granville@gmail.com>  writes:
>
>> On Thursday, July 18, 2013 11:44:37 PM UTC+12, Anssi Saari wrote:
>>> BTW, apparently Altera is coming up with small FPGAs along the lines of
>>> Lattice's MachXO2 line. It's funny how the XO2-1200 seems like a MaxII
>>> EPM1270 with 10 more LEs, a PLL and some RAM...

Yeah, the low end has been explored pretty well.  Now it is just a 
matter of coming out with variations on the theme which give the best 
combination of support for a variety of designs.  If the low end takes 
off, I don't see why it won't blossom like MCUs where there are lots and 
lots of different products with just the right combination of 
capabilities for nearly any task.


>> Any indications of when ?
>
> I think it was 2014. I may have some notes somewhere but they were
> pretty vague on everything.

I just got an EOL notice on a Lattice XP part I'm using.  My product has 
a lot of life left in it and I will have to redesign with a newer part. 
  With any luck I'll be able to include a lot more capability.  The 
present device is around 80% full.

At least I know what I'll be doing for the next project!

The notice is a bit short, only four months warning to get your final 
orders in.

-- 

Rick

Article: 155592
Subject: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Fri, 26 Jul 2013 17:22:36 +0200
Links: << >>  << T >>  << A >>
Hi all,

I have the following specs for the physical level of a serial protocol:

> For the communication with Frontend asynchronous LVDS connection is used.
> The bitrate is set to 20 Mbps.
> Data encoding on the LVDS line is NRZI:
> - bit '1' is represented by a transition of the physical level,
> - bit '0' is represented by no transition of the physical level,
> - insertion of an additional bit '1' after 6 consecutive bits '0'.

Isn't there a missing requirement on reset condition of the line?
System clock is implicitly defined on a different section of the specs
and is set at 40MHz.

At the next layer there's a definition of a 'frame' as a sequence of 16
bit words preceded by a 3 bit sync pattern (111) and a header of 16 bits
defining the type of the packet and the length of the packet (in words).

I'm writing a test bench for it and I was wondering whether there's any
recommendation you would suggest. Should I take care about randomly
select the phase between the system clock and the data?

Any pointer is appreciated.
Cheers,

Al

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 155593
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Fri, 26 Jul 2013 19:59:46 -0400
Links: << >>  << T >>  << A >>
On 7/26/2013 11:22 AM, alb wrote:
> Hi all,
>
> I have the following specs for the physical level of a serial protocol:
>
>> For the communication with Frontend asynchronous LVDS connection is used.
>> The bitrate is set to 20 Mbps.
>> Data encoding on the LVDS line is NRZI:
>> - bit '1' is represented by a transition of the physical level,
>> - bit '0' is represented by no transition of the physical level,
>> - insertion of an additional bit '1' after 6 consecutive bits '0'.
>
> Isn't there a missing requirement on reset condition of the line?
> System clock is implicitly defined on a different section of the specs
> and is set at 40MHz.
>
> At the next layer there's a definition of a 'frame' as a sequence of 16
> bit words preceded by a 3 bit sync pattern (111) and a header of 16 bits
> defining the type of the packet and the length of the packet (in words).
>
> I'm writing a test bench for it and I was wondering whether there's any
> recommendation you would suggest. Should I take care about randomly
> select the phase between the system clock and the data?

Async, eh?  At 2x clock to data?  Not sure I would want to design this. 
  I assume you have to phase lock to the data stream somehow?  I think 
that is the part I would worry about.

In simulation I would recommend that you both jitter the data clock at a 
high bandwidth and also with something fairly slow.  The slow variation 
will test the operation of your data extraction with a variable phase 
and the high bandwidth jitter will check for problems from only having 
two samples per bit.  I don't know how this can be expected to work myself.

I did something similar where I had to run a digital phase locked loop 
on standard NRZ data (no encoding) and used a 4x clock, but I think I 
proved to myself I could do it with a 3x clock, it just becomes 
impossible to detect when you have a sample error... lol.

-- 

Rick

Article: 155594
Subject: vtr and at40k
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Sat, 27 Jul 2013 03:18:50 +0200
Links: << >>  << T >>  << A >>
Hello,
Has anybody ever attempted to craft a libarchfpga architecture file for 
the at40k FPGAs? As I understand it, verilog-to-routing is supposed to 
route a design on an FPGA arch, and the xml file describes the topology. 
However, I cannot seem to fit the repeaters anywhere... they're neither 
part of the switch box, nor part of the connection box... but those two 
are the only things I can specify for wire segments!?


Article: 155595
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Sun, 28 Jul 2013 20:32:59 +0200
Links: << >>  << T >>  << A >>
On 27/07/2013 01:59, rickman wrote:
> On 7/26/2013 11:22 AM, alb wrote:
>> Hi all,
>>
>> I have the following specs for the physical level of a serial protocol:
>>
>>> For the communication with Frontend asynchronous LVDS connection is
>>> used.
>>> The bitrate is set to 20 Mbps.
>>> Data encoding on the LVDS line is NRZI:
>>> - bit '1' is represented by a transition of the physical level,
>>> - bit '0' is represented by no transition of the physical level,
>>> - insertion of an additional bit '1' after 6 consecutive bits '0'.
>>
[]
> 
> Async, eh?  At 2x clock to data?  Not sure I would want to design this.
>  I assume you have to phase lock to the data stream somehow?  I think
> that is the part I would worry about.

currently they are experiencing a large loss of packets as well as many
corrupted packets (CRC errors). I'm not sure the current implementation
is doing phase lock.

> 
> In simulation I would recommend that you both jitter the data clock at a
> high bandwidth and also with something fairly slow.  The slow variation
> will test the operation of your data extraction with a variable phase
> and the high bandwidth jitter will check for problems from only having
> two samples per bit.  I don't know how this can be expected to work myself.

Since modules are likely to have different temperatures being far apart,
I would certainly expect a phase problem. Your idea to have a slow and a
high frequency variation in the phase generation might bring out some
additional info.

> 
> I did something similar where I had to run a digital phase locked loop
> on standard NRZ data (no encoding) and used a 4x clock, but I think I
> proved to myself I could do it with a 3x clock, it just becomes
> impossible to detect when you have a sample error... lol.

what do you mean by saying 'it becomes impossible to detect when you
have a sample error'?


Article: 155596
Subject: Re: serial protocol specs and verification
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 28 Jul 2013 21:05:36 -0400
Links: << >>  << T >>  << A >>
On 7/26/13 11:22 AM, alb wrote:
> Hi all,
> 
> I have the following specs for the physical level of a serial protocol:
> 
>> For the communication with Frontend asynchronous LVDS connection is used.
>> The bitrate is set to 20 Mbps.
>> Data encoding on the LVDS line is NRZI:
>> - bit '1' is represented by a transition of the physical level,
>> - bit '0' is represented by no transition of the physical level,
>> - insertion of an additional bit '1' after 6 consecutive bits '0'.
> 
> Isn't there a missing requirement on reset condition of the line?
> System clock is implicitly defined on a different section of the specs
> and is set at 40MHz.
> 
> At the next layer there's a definition of a 'frame' as a sequence of 16
> bit words preceded by a 3 bit sync pattern (111) and a header of 16 bits
> defining the type of the packet and the length of the packet (in words).
> 
> I'm writing a test bench for it and I was wondering whether there's any
> recommendation you would suggest. Should I take care about randomly
> select the phase between the system clock and the data?
> 
> Any pointer is appreciated.
> Cheers,
> 
> Al
> 

You don't need to specify a reset state, as either level will work. At
reset the line will be toggling every 7 bit times due to the automatic
insertion of a 1 after 6 0s.

I would be hard pressed to use 40 MHz as a system clock, unless I was
allowed to use both edges of the clock (so I could really sample at a 4x
rate).

For a test bench, I would build something that could be set to work
slightly "off frequency" and maybe even with some phase jitter in the
data clock. I am assuming that system clock does NOT travel between
devices, or there wouldn't be as much need for the auto 1 bit, unless
this is just a bias leveling, but if isn't real great for that.

Article: 155597
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Mon, 29 Jul 2013 11:09:32 +0200
Links: << >>  << T >>  << A >>
On 29/07/2013 03:05, Richard Damon wrote:
> On 7/26/13 11:22 AM, alb wrote:
>> Hi all,
>>
>> I have the following specs for the physical level of a serial protocol:
>>
>>> For the communication with Frontend asynchronous LVDS connection is used.
>>> The bitrate is set to 20 Mbps.
>>> Data encoding on the LVDS line is NRZI:
>>> - bit '1' is represented by a transition of the physical level,
>>> - bit '0' is represented by no transition of the physical level,
>>> - insertion of an additional bit '1' after 6 consecutive bits '0'.
>>
>> Isn't there a missing requirement on reset condition of the line?
>> System clock is implicitly defined on a different section of the specs
>> and is set at 40MHz.
[]
> You don't need to specify a reset state, as either level will work. At
> reset the line will be toggling every 7 bit times due to the automatic
> insertion of a 1 after 6 0s.

Uhm, since there's a sync pattern of '111' I have to assume that no
frame is transmitted when only zeros are flowing (with the '1' stuffed
every 6 zeros).

> I would be hard pressed to use 40 MHz as a system clock, unless I was
> allowed to use both edges of the clock (so I could really sample at a 4x
> rate).

I'm thinking about having a system clock multiplied internally via PLL
and then go for a x4 or x8 in order to center the bit properly.

> 
> For a test bench, I would build something that could be set to work
> slightly "off frequency" and maybe even with some phase jitter in the
> data clock. 

Rick was suggesting a phase jitter with a high and a low frequency
component. This can be even a more realistic case since it models slow
drifts due to temperature variations... I do not know how critical would
be to simulate *all* jitter components of a clock (they may depend on
temperature, power noise, ground noise, ...).

> I am assuming that system clock does NOT travel between
> devices, or there wouldn't be as much need for the auto 1 bit, unless
> this is just a bias leveling, but if isn't real great for that.

Your assumption is correct. No clock distribution between devices.


Article: 155598
Subject: Instruction time (lwi) on Microblaze
From: "dlaur" <98245@embeddedrelated>
Date: Mon, 29 Jul 2013 09:53:09 -0500
Links: << >>  << T >>  << A >>
Hi,

I'm trying to accomodate with microblaze on a spartan starter kit 3a board
and now I'm looking into measuring execution time of different things. I
have a small loop that I'm analysing:

while(1)
 {
  if (intr_served==1) // this is set by an interrupt handler triggered by a
FIT timer running at 1 second
    {
     intr_served=0;
     num=0; //resets the global counter
    }
  num++;
 }

Microblaze is running at 62500000 with the following specs:

BEGIN microblaze
 PARAMETER INSTANCE = microblaze_0
 PARAMETER C_AREA_OPTIMIZED = 0
 PARAMETER C_USE_BARREL = 1
 PARAMETER C_DEBUG_ENABLED = 0
 PARAMETER HW_VER = 8.40.b
 PARAMETER C_USE_ICACHE = 0
 PARAMETER C_CACHE_BYTE_SIZE = 2048
 PARAMETER C_USE_DCACHE = 0
 PARAMETER C_DCACHE_BYTE_SIZE = 2048
 PARAMETER C_NUMBER_OF_PC_BRK = 1
 PARAMETER C_NUMBER_OF_RD_ADDR_BRK = 0
 PARAMETER C_NUMBER_OF_WR_ADDR_BRK = 0
 BUS_INTERFACE DPLB = mb_plb
 BUS_INTERFACE IPLB = mb_plb
 BUS_INTERFACE DLMB = dlmb
 BUS_INTERFACE ILMB = ilmb
 PORT INTERRUPT = microblaze_0_interrupt
 PORT Trace_PC = microblaze_0_Trace_PC_to_chipscope_ila_0
 PORT Trace_Valid_Instr =
microblaze_0_Trace_Valid_Instr_to_chipscope_ila_0
 PORT Trace_Data_Read = microblaze_0_Trace_Data_Read_to_chipscope_ila_0
 PORT Trace_Data_Write = microblaze_0_Trace_Data_Write_to_chipscope_ila_0
 PORT Trace_Data_Address =
microblaze_0_Trace_Data_Address_to_chipscope_ila_0
 PORT Trace_Reg_Addr = microblaze_0_Trace_Reg_Addr_to_chipscope_ila_0
 PORT Trace_Reg_Write = microblaze_0_Trace_Reg_Write_to_chipscope_ila_0
 PORT Trace_OF_PipeRun = microblaze_0_Trace_OF_PipeRun_to_chipscope_ila_0
 PORT Trace_MEM_PipeRun =
microblaze_0_Trace_MEM_PipeRun_to_chipscope_ila_0
 PORT Trace_EX_PipeRun = microblaze_0_Trace_EX_PipeRun_to_chipscope_ila_0
 PORT Trace_MB_Halted = microblaze_0_Trace_MB_Halted_to_chipscope_ila_0
END

I don't have any DDR memory. The code runs from BRAM.

When i check out the code with chipscope to see how many clock cycles my
loop takes, I notice that the lwi instruction takes more than 1 cycle, as
written in the manual. Any ideas why this happens ?

Any ideas will be greatly appreciated :)

Thanks !

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155599
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Mon, 29 Jul 2013 11:19:44 -0400
Links: << >>  << T >>  << A >>
On 7/28/2013 2:32 PM, alb wrote:
> On 27/07/2013 01:59, rickman wrote:
>> On 7/26/2013 11:22 AM, alb wrote:
>>> Hi all,
>>>
>>> I have the following specs for the physical level of a serial protocol:
>>>
>>>> For the communication with Frontend asynchronous LVDS connection is
>>>> used.
>>>> The bitrate is set to 20 Mbps.
>>>> Data encoding on the LVDS line is NRZI:
>>>> - bit '1' is represented by a transition of the physical level,
>>>> - bit '0' is represented by no transition of the physical level,
>>>> - insertion of an additional bit '1' after 6 consecutive bits '0'.
>>>
> []
>>
>> Async, eh?  At 2x clock to data?  Not sure I would want to design this.
>>   I assume you have to phase lock to the data stream somehow?  I think
>> that is the part I would worry about.
>
> currently they are experiencing a large loss of packets as well as many
> corrupted packets (CRC errors). I'm not sure the current implementation
> is doing phase lock.
>
>>
>> In simulation I would recommend that you both jitter the data clock at a
>> high bandwidth and also with something fairly slow.  The slow variation
>> will test the operation of your data extraction with a variable phase
>> and the high bandwidth jitter will check for problems from only having
>> two samples per bit.  I don't know how this can be expected to work myself.
>
> Since modules are likely to have different temperatures being far apart,
> I would certainly expect a phase problem. Your idea to have a slow and a
> high frequency variation in the phase generation might bring out some
> additional info.
>
>>
>> I did something similar where I had to run a digital phase locked loop
>> on standard NRZ data (no encoding) and used a 4x clock, but I think I
>> proved to myself I could do it with a 3x clock, it just becomes
>> impossible to detect when you have a sample error... lol.
>
> what do you mean by saying 'it becomes impossible to detect when you
> have a sample error'?

I was assuming that perhaps you were doing something I didn't quite 
understand, but I'm pretty sure I am on target with this.  You *must* up 
your sample rate by a sufficient amount so that you can guarantee you 
get a minimum of two samples per bit.  Otherwise you have no way to 
distinguish a slipped sample due to clock mismatch.  Clock frequency 
mismatch is guaranteed, unless you are using the same clock somehow.  Is 
that the case?  If so, the sampling would just be synchronous and I 
don't follow where the problem is.

It is not just a matter of phase, but of frequency.  With a 2x clock, 
seeing a transition 3 clocks later doesn't distinguish one bit time from 
two bit times.

I'm having trouble expressing myself I think, but I'm trying to say the 
basic premise of this design is flawed because the sample clock is only 
2x the data rate.  I say you need 3x and I strongly encourage 4x.  At 4x 
the samples have four states, expected timing, fast timing, slow timing 
and "error" timing meaning the loop control isn't working.

Data     ____----____----____----____----____----____----____
SmplClk  --__--__--__--__--__--__--__--__--__--__--__--__--__
SmplData -----____----____----____----____----____----____----

This is how you expect it to work.  But if the data is sampled slightly 
off it looks like this.

Data     ____---____----____----____----____----____----____
SmplClk  --__--__--__--__--__--__--__--__--__--__--__--__--__
SmplData -----________----____----____----____----____----___

You can't use a locked loop like this because you have no info on 
whether you are sampling fast or slow.

The sample clock does not need to be any particular ratio to the data 
stream if you use an NCO to control the sample rate.  Then the phase 
detection will bump the rate up and down to suit.

Do you follow what I am saying?  Or have I mistaken what you are doing?

-- 

Rick



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
2017JanFebMarApr2017

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