Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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. -- GaborArticle: 155576
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
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.comArticle: 155578
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: 155579Hi, 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
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: 155581Leo 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. -- GaborArticle: 155582
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
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. TheoArticle: 155584
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
> 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"; HTHArticle: 155586
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. TheoArticle: 155587
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
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. TheoArticle: 155589
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. TheoArticle: 155590
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: 155591On 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. -- RickArticle: 155592
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
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. -- RickArticle: 155594
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
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
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
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
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: 155599On 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:
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