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 123925

Article: 123925
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Fri, 07 Sep 2007 04:55:26 -0000
Links: << >>  << T >>  << A >>
> We run the EMAC 8 bits wide at 125 MHz, and the PicBlaze at 62.5 MHz
> using a divided by two version of the EMAC clock.  The PicoBlaze takes
> two cycles per instruction, and the packets we are offloading are a
> bit over 1KB, so we about 512 instructions to deal with an offloaded
> packet and other overhead.  Dealing with a non-offloaded packet takes
> the shortest path through the code to keep the number of packets per
> second we can handle up.  The network the data is on is tightly
> controlled, so there is very little on it that is not the protocol we
> are offloading, mostly just IGMP packets for dealing with the
> multicast groups, and they are at a very low rate.
>
> You are correct in that we do not look at the entire packet with the
> PicoBlaze, just the header.  Once it has determined that it wants to
> offload that packet, it then has a little bit more work to do to
> calculate addresses and load them into the DMA engine.  To make sure
> that we do not drop packets, we just need to make sure that the
> longest path through the code takes less time than about how long it
> takes to receive a packet.  We have a FIFO between the EMAC and the
> DMA engine, so we can smooth things out a bit.
>

Thanks for the information. I must say I'm impressed with your design
- a great interoperability of logic, cores, small and large CPUs and
software.

Eli



Article: 123926
Subject: Re: VCCAUX too high on a Spartan 3 design
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 06 Sep 2007 22:00:41 -0700
Links: << >>  << T >>  << A >>
On Sep 6, 9:03 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Peter Alfke wrote:
>
> >>>The regulator output voltage is controlled by just 2 resistors.  When I
> >>>changed one of the resistors to lover the voltage a bit, VCCAUX did not
> >>>change.  This leads me to believe that VCCAUX is somehow being "back"
> >>>powered from the Xilinx chip.  These voltages are present like this before
> >>>the Xilinx chip has been programmed.  I have not removed the regulator to
I should have expressed this better: Use the extra pull-down resistor
just as an experiment to see whether the problem really is reverse
current going into the regulator, or is something else. Just
temporarily, just attach the resistor lightly, by hand if possible...
Peter Alfke

> >>>measure current yet.  Another thought was to put a shotkey diode between
>
> > I would load the Vccaux pin with a 100 Ohm resistor to ground. That
> > adds 25 mA to the regulated current.
> > Normall, this should hardly change the voltage, but if the regulator
> > is back-fed, there will be a big voltage drop.
> > Parallel resistors to ground are nice and easy, and do not cuase any
> > irrepairable tdamage.
>
> You can also drop the values of the two SET resistors, then you do not
> need to change the PCB design.
>
> -jg



Article: 123927
Subject: Re: Clock boundary crossing
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 07 Sep 2007 00:34:11 -0500
Links: << >>  << T >>  << A >>
>Although a little dated, I've found this 10 Commandments of Excellent
>Design article useful.
>
>http://www.bawankule.com/verilogcenter/files/10_1.pdf

It's actually pretty good, but I'm in a nit-picking mood,
so here goes...


On page 10:

> If your silicon library supports metastable-hardened flip-flops, then
> the first stage should use such a device. Typically,
> metastable-hardened flip-flops guarantee that their Q outputs will
> settle after a given maximum time, no matter how close the data
> transition is to the flip-flop s clock edge.

Where can I buy one?  :)

Why does that rumor/myth keep propagating?

If you understand metastability, it is (or was) a pretty good
way to get a quick calibration on a text book.  Look in the index.
If there is something there, read that section.  Does it match
what you know?  Would you get the idea from reading the text
if you didn't alread know the answer?



On page 14:

> 2. Noisy Latch Enable
> Perhaps worse than noise on latch inputs is noise on the enable line.
> If a latch enable glitches as a result of an asynchronous decode, your
> design is toast. The first part of this article discussed how to
> eliminate glitches on decoded signals; but if you get it wrong, a
> register-based design is still likely to be robust, since glitches on
> clock enables don t matter except when the clock transitions. Glitches
> on latch enables always mean instant death whenever they occur.

Gated clocks have similar problems.  The gate can't glitch while the
clock is active.

This is really just more setup/hold times.  The quirk is that the
must-be-stable time is much larger than people are used to thinking
about for the Q input to simple FFs.

Tools should get this right.  If they don't, users should scream.



On page 15, he discusses clock skew and a pair of FFs connected with
no logic.  His suggested fix is a delay between the FFs.

> Some synthesizer tools have a fix hold option which claims to take
> care of this situation. But if your design fails, who gets the blame:
> the designer or some well-hidden option in a synthesizer? Check
> carefully for fast paths.

The important point is that hold time has to cover clock skew.

Again, vendors with buggy tools deserve a lot of bad PR and users
should give it to them.

Some systems (tools plus silicon) work on a 0-hold time basis
so they don't have to worry about hold time.  (It saves 1/2
the computing when the tools are checking setup/hold.)  But that
has to cover clock skew.

The nasty case that I know of is "skew" from two different outputs
of the same DCM.  Do the Xilinx tools cover that yet?



Page 17:

> Asynchronous feedback paths are a federal offense
...
> If there are unclocked feedback paths in your design, make sure
> that they can be broken and analyzed from the tester. Better
> still, get rid of them altogether.

Somebody asked about this recently.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123928
Subject: Re: high bandwitch ethernet communication
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 22:14:51 -0800
Links: << >>  << T >>  << A >>
Paul Keinanen wrote:

(snip)

> If the OP required only something dedicated point to point
> connectivity, why bother with the IP wrapper, just send raw Ethernet
> frames with MAC addressing ?

You could, but sending UDP isn't that much harder.  If you really want
to simplify it, put the destination MAC address in as a constant
(saves doing ARP, but ARP could also be done in external software
and the result written to the FPGA).  The next complication is
generating the CRC for UDP, but that is optional.  The ethernet
CRC has to be generated in either case.

http://www.networksorcery.com/enp/protocol/udp.htm

(snip)

> The hard thing is to get the transmit data into the transmit buffers
> fast enough, but for direct port to port copying, there should not be
> much need to move the actual data in the memory.

If the FPGA isn't fast enough, write it out in 8 bit parallel and
use an external shift register.

-- glen


Article: 123929
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 22:24:23 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:
>>Consider a sphere with no other metal objects around it.
>>Add some charge and compute the change in voltage.
>>Divide, and that is the capacitance.  It is a little harder
>>to calculate for other shapes, but it is still there.

> If there is nothing else nearby, where are you putting
> the other probe on your voltmeter?

Voltage is the energy needed to move a charge from infinity
to the point in question.  That is true whether or not you
have a voltmeter.

-- glen


Article: 123930
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 23:08:19 -0800
Links: << >>  << T >>  << A >>
PeteS wrote:
(snip on differential signals changing planes)

>> I think it does matter in this case. I think we're agreed that the two 
>> signals that make up the pair are mainly coupled to the plane, not to 
>> each other. This means that current is flowing in the ground. As you 
>> say in another reply in this thread to me, that doesn't matter, UNTIL 
>> the signals come to a discontinuity in the 'signal to ground' 
>> coupling. Such a situation arises at the transition between layers, 
>> which is why the use of adjacent ground vias can mitigate the situation.

If you come in perpendicular to the plane split, there should
not be any effect.  The net current crossing the split in the
signal conductors is zero, it also must be in the ground planes.
That is, the currents in the ground plane are perpendicular to
the signal wires.

> The vast majority of 'differential signals' on PCBs are *not* true 
> differential (balanced) signals. They need the reference plane 
> (sometimes called ground which is really a little confusing) for return 
> currents.

Well, then they aren't differential.

> A balanced signal does not need a reference except it's inverse - that 
> is NOT true of PCB differential signals in 99% of cases.

Well, then the question is, is it close enough.  I can't say.

> Break the return path and you break the impedance control - it really is 
> that simple.

Then it gets back to the non-differential case.  There may or may
not be enough capacitance around.  What fraction of the current
is common mode?

-- glen


Article: 123931
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 23:14:16 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:
(snip)

> If a diff signal hits a region where the impedance changes, there will
> be a partial differential reflection, kicked back to the driver.
> Unless the driver is a matched impedance, which it generally ain't,
> the reflection will bounce off the driver and get tangled with the
> data stream, introducing jitter and closing up the data eye.

That is true, but it is separate from the question of crossing
planes.

> The differential impedance is determined by both signal-ground
> capacitance and signal-signal capacitance (which gets double credit).
> For a very fast edge, a diff signal that changes layers on vias can
> encounter a different impedance region and do some bouncing. The fast
> parts of the signal will tend to bounce back, and the slow parts will
> tend to pass forward, not good. The via structure can certainly be
> optimized for signal integrity. Above a few hundred ps risetime, it's
> generally not a big deal.

The length of the impedance discontinuity could (or should) be
very short.  If it gets back to the right impedance on the
other side, the reflections will cancel.  Again, separate from
the question of split planes.

-- glen


Article: 123932
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 23:23:38 -0800
Links: << >>  << T >>  << A >>
Symon wrote:
(snip, someone else wrote)

>>The signal is differential so when the return currents hit the wall, they 
>>cancel each other out at that border.  There's no reflection because the 
>>common mode voltage isn't changing.  If the differential signal wasn't 
>>routed differentially, then the reference currents would disperse when 
>>they hit the discontinuity and then eventually find each other or other 
>>ways to balance the current.  Even though a large portion of the reference 
>>current is in the plane, the discontinuity results in almost no distance 
>>to travel for the differential reference currents to find peace.

That depends on good board layout, but should be true.  Especially
one should be sure that the capacitance (per unit length) from the two
to ground are equal.

> A good point, I agree, that's true. As you say, there will be a 
> discontinuity nevertheless, as the currents need to cancel out across the 
> plane, but I would think this is a small effect. Furthermore, in that case, 
> I think it means it is important to match the lengths of the traces from 
> each termination to the vias as well as the total length of the individual 
> traces. In the case where the extra ground vias are in place, that isn't so 
> important.

For a true differential signal the ground plane current is perpendicular
to the signal wires.  Yes, that does depend on the conditions being
close enough to the same for the two wires.

> Of course, the differential signal continues on its merry way through the 
> vias. Without the ground vias, the transmission line impedance will have a 
> significant discontinuity.

It is important that the impedance be the same on both sides.  The
length of the via itself should be much less than the wavelength,
and so should have a relatively small effect.

I was thinking of the case where the signals stay in the same layer,
but switch reference planes.  If one is careful with the edges of the
planes, it should be possible to minimize the discontinuity.

-- glen


Article: 123933
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 06 Sep 2007 23:27:12 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:

(snip)

>>Consider a sphere with no other metal objects around it.
>>Add some charge and compute the change in voltage.
>>Divide, and that is the capacitance.  It is a little harder
>>to calculate for other shapes, but it is still there.

> 1 cm radius is 1 pF!

In CGS units the unit of capacitance is cm.
(resistance is s/cm and inductance s**2/cm.)

-- glen


Article: 123934
Subject: Re: load/read/ commands assembly PowerPC. Help Needed!
From: xenix <lastval@gmail.com>
Date: Fri, 07 Sep 2007 08:25:18 -0000
Links: << >>  << T >>  << A >>
yes the MMU function of the PowerPC is ON.

Regards


Article: 123935
Subject: Re: ?Nios II?How Can I Find Out These Functions ?
From: lexluthor <hezhikuan2007@gmail.com>
Date: Fri, 07 Sep 2007 02:06:46 -0700
Links: << >>  << T >>  << A >>
Thank you very much!




Article: 123936
Subject: Re: ANNC: New Boundary-Scan Software
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Fri, 07 Sep 2007 09:17:59 -0000
Links: << >>  << T >>  << A >>
On 7 Sep., 01:11, sksw...@gmail.com wrote:
> > Does it tun on Unix/Linux?
>
> No, currently only Windows. But it's written using cross-platform GUI
> library with the idea to be easily ported to Linux if there will be a
> market for it.

You should be aware, that while the FPGA-world is mostly PC and
Windows based,
traditionally most ASIC design applications run on Solaris and other
Unix variants only,
with Linux gaining ground.

Kolja Sulimma


Article: 123937
Subject: [Nios II] How does the PIO Core generate a interrupt?
From: lexluthor <hezhikuan2007@gmail.com>
Date: Fri, 07 Sep 2007 02:20:09 -0700
Links: << >>  << T >>  << A >>

I have designed a counter, it works like this: when the counter reach
a number , one of its output pins generate a high level signal, this
pin connects with the SOPC module. How can I  achieve this goal : when
the pin's level changes, the PIO core generates a interrupt, in other
words, how can I register this type interrupt?

Thank you very much!


Article: 123938
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 7 Sep 2007 10:56:41 +0100
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> wrote in message 
news:5kb550F2v2a0U1@mid.individual.net...
> "John_H" <newsgroup@johnhandwork.com> wrote in message 
> news:13e0m5eprs3aje6@corp.supernews.com...
>>
>> If the design can still be altered, a different clock might be used to 
>> feed the DCMs in the first place (such as 70 MHz to generate all the 
>> clocks, even what was the system clock) or go through an external jitter 
>> clean-up clock chip to then feed the DCMs.
>>
>> With the architecture fixed as it is now, it won't work.
>
> The design can be altered but at a high cost, as I will need to redesign 
> many other pieces...
>
> /Mikhail
>
Hi Mikhail,

How about not generating the clocks, but clock enables from the 210MHz 
signal? For example, to make the ~96.55MHz signal:-

if rising_edge(clk_210) then
  if accum >= 64 then
    enable_96 <= '1';
    accum <= accum - 47;
  else
    enable_96 <= '0';
    accum <= accum + 40;
  end if;
end if;

Then use the 210MHz clock with the enable? Probably not much more jittery 
than the cascaded DCMs!

BTW, the ~38.62MHz signal can be generated by dividing the 210MHz by three 
in regular logic and feeding this 70MHz to the DCM. IIRC, only the rising 
edge is important to the CLKIN of the DCM, so the mark-space ratio after the 
divide by three isn't a problem.

HTH, Syms.



Article: 123939
Subject: Re: VCCAUX too high on a Spartan 3 design
From: vasile <piclist9@gmail.com>
Date: Fri, 07 Sep 2007 10:01:27 -0000
Links: << >>  << T >>  << A >>
On Sep 7, 8:00 am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Sep 6, 9:03 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:> Peter Alfke wrote:
>
> > >>>The regulator output voltage is controlled by just 2 resistors.  When I
> > >>>changed one of the resistors to lover the voltage a bit, VCCAUX did not
> > >>>change.  This leads me to believe that VCCAUX is somehow being "back"
> > >>>powered from the Xilinx chip.  These voltages are present like this before
> > >>>the Xilinx chip has been programmed.  I have not removed the regulator to
>
> I should have expressed this better: Use the extra pull-down resistor
> just as an experiment to see whether the problem really is reverse
> current going into the regulator, or is something else. Just
> temporarily, just attach the resistor lightly, by hand if possible...
> Peter Alfke

Unfortunately increasing the power dissipation with sinking/sourcing
LDO on VCCAUX or external loads can't be the final solution. If there
is a leackage current path from VCCIO to VCCAUX that must be founded
and supressed somehow.
Using series schottky between VCCAUX and FPGA will drop the output
voltage to VCCAUX - (0.3V...0.7V) depending on load current and diode
type.

Vasile


Article: 123940
Subject: Re: high bandwitch ethernet communication
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 07 Sep 2007 12:44:38 +0200
Links: << >>  << T >>  << A >>
eliben wrote:
> Hello,
> 
> In our application we have to receive and merge several proprietary
> serial channels (200 MHz) over fibers, and send all the data over
> Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained.
> 
> While generally sending this amount of data is possible over Gbit
> Ethernet, doing so in an embedded system isn't easy. That's because we
> need to send it by UDP or TCP, for which a TCP/UDP/IP stack is
> required (software).
> 
> Since the translation of the proprietary format is certainly done in
> an FPGA, I tried to calculate how to implement the whole process in an
> FPGA. For example, I can take an Altera Stratix II GX (with a built in
> Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on
> the Nios II soft-core processor. Unfortunately, as Altera's appnote
> 440 shows, the maximal bandwidth attainable this way is only 15-17
> MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet
> adapters on PCs show a maximal bandwidth of 80-90 MByte/s.
> 
> However, I wouldn't like to build in a Pentium into the embedded
> system. Any suggestions / recommendations on how to solve the
> problem ?
> 
> Thanks in advance
> 

There are a number of things that can be used to speed up the Ethernet 
communication (I've read about these, but not tried them - but they 
might give you a clue).

On the software side, there are a number of different tcp/ip stacks 
available, and the particular implementation can make a lot of difference.

In the FPGA, you can make sure you are using DMA for memory transfers 
rather than cpu memory accesses.  You can also use the FPGA to 
accelerate things like CRC calculations enormously - perhaps you can get 
these ready-written, or make one yourself, and modify the stack to use it.

There are also several different Ethernet MAC's available, with widely 
different throughputs.  Have a look at the OpenCores lists and try some 
out (I gather the prices are not insignificant, but they may be worth 
the money).

mvh.,

David

Article: 123941
Subject: Re: New keyword 'orif' and its implications
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 07 Sep 2007 11:58:54 +0100
Links: << >>  << T >>  << A >>
On Thu, 06 Sep 2007 07:53:25 -0700, Weng Tianxiang <wtxwtx@gmail.com>
wrote:

>Hi Brian,
>1. Please write target answer's name, otherwise I may miss your
>comments.
>
>2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
>you see any burning?

Back in the TTL days, yes.

>3. The following claim is irrelative to Andy's requirement:
>"Andy's code caught the problem before synthesis, so he fixed it.
>Because his synthesis tool (the 2008 version) understood the
>assertion"
>
>Andy wants me to use orif to transfer mutually exclusive information
>to within loop, in this respect, no orif is needed and things are done
>perfectly, because mutually exclusive Information has been clearly
>transfered to within the loop by coding style.

it's exactly relevant because in his example, the ONLY mutually
exclusive information IS the assertion. In your counterexample I don't
see any such information, despite the fact that you are free to use
"orif".

>Whatever assertion onehot0() can do in terms of mutually exclusive
>information tranfer mechanism, orif can do better, faster, safer and
>more reliable !

This has still not been demonstrated for this example.

- Brian

Article: 123942
Subject: Re: Xilinx FPGA Based Board Problem
From: Piyush Kaul <piyushkaul@gmail.com>
Date: Fri, 07 Sep 2007 11:26:10 -0000
Links: << >>  << T >>  << A >>
Thanks Martin & SKatsy for your suggestions

I have tried out using the pin low instead of high and also checked
and rechecked the pin configuration. All that seems to be fine so I
have begun doubting the board.

I will check the scanseer utility and see if that helps.

Regards
Piyush

On Aug 31, 7:40 pm, SKatsy...@gmail.com wrote:
> > Hi All,
>
> > I am new to FPGAs and my main interest is implementation of some
> > signal processing algorithms on FPGAs. For testing the MEMEC  (DS-BD-
> > V2MB1000) board which has a xc2vc1000 fpga on it along with a xc18v04,
> > I was trying to write a simple module. I am using the impact Parallel
> > IV cable for download of my code.
>
> > I started with a simple VHDL code for a counter to be displayed on 7-
> > segment display. Since it did not work, I slowly started removing code
> > and now I have a single
> > line in the architecture
>
> > architecture board of testLed  is
> > begin
> >         led <= '1';
> > end board;
>
> > The "led" is the user led provided on the board.
>
> > Don't think it can get any simpler. But even this doesn't seem to
> > work. I am using the JTAG interface available on the board. The
> > boundary scan is working perfectly and detecting the FPGA & PROM.
> > After bypassing the PROM, I am loading the bit file on the FPGA.
>
> > I am using Xilinx ISE Foundation 6.2 & XST for synthesis and have also
> > assigned the pins through PACE. The edit contraints show the following
> > text.
>
> > NET "led" LOC = "A9"
>
> > Any suggestions regarding the possible cause of what I may be missing
> > will be welcome.
>
> > Regards
> > Piyush
>
> Try to light the led with a boundary-scan software like Scanseer
> (http://www.scanseer). Put your FPGA in EXTEST mode and manipulate
> with its pins' signals. This way you can check PCB interconnections.



Article: 123943
Subject: Re: PCB Impedance Control
From: Andrew Burnside <andrew.burnside@sli-institute.ac.uk>
Date: Fri, 07 Sep 2007 05:35:00 -0700
Links: << >>  << T >>  << A >>
>
> Bizarre. This guy can't even afford real pc boards, so has to fake it
> with wire and old copperclad. Fig 3 is hilarious; of course a signal
> radiates more on the side it's exposed to the antenna. Of course vias
> are inductive discontinuties.

On the assumption that people aren't trolling, and to save people's
time I would suggest that the Signal Integrity mailing list is perhaps
a better place to continue. Everyone on that list has an interest in
SI, so perhaps a more informed debate can continue.
(Note: this is not saying that John or the other side is incorrect,
just a suggestion)

See http://www.freelists.org/list/si-list for the web interface.

Andrew


Article: 123944
Subject: How to simple convert a hex or mif file from Altera to Xilinx coe
From: Bernard Esteban <esteban.bernard***spam***@wanadoo.fr>
Date: Fri, 07 Sep 2007 15:12:34 +0200
Links: << >>  << T >>  << A >>
Hi,

How to simple convert a hex or mif file from Altera to Xilinx coe file?

Do you know any little software?

Regards

Bernard Esteban
MAF Agrobotic

Article: 123945
Subject: SRAM on Cyclone Devices
From: "devices" <me@home>
Date: Fri, 7 Sep 2007 15:21:16 +0200
Links: << >>  << T >>  << A >>
Target Device: CYCLONE

My project allocates some RAM and initializes
it by an Intel Hex File. The Simulator correctly
shows the initialized data.

<CODE>

  lpm_ram_dq   ram
   (
      .address   (_addr),
      .q         (_dout),
      .data      (_di),
      .we        (_we),
      .inclock   (clk),
      .outclock  (!clk)
   );

   defparam ram.lpm_width   = 8;
   defparam ram.lpm_widthad = 11;
   defparam ram.lpm_file    = "-----.hex";
   defparam ram.lpm_indata  = "REGISTERED";
   defparam ram.lpm_outdata = "REGISTERED";

   defparam ram.lpm_address_control
     = "REGISTERED";

   defparam ram.lpm_hint    =
     "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=AAAA";

</CODE>

I'm not sure the synthesizer/programmer initialize
the sram on the real device. I thought

1) i could check it out by using Quartus II
"In-System Memory Content Editor".

I also thought

2) that by inspecting the ram content i can check
whether my design is working as required.

But if i enable the ISMC Editor (the last defparam),
the compiler gives the following error:

"Insufficient resources available on RAM to use
In-System Memory Content Editor"

I guess that for "Device Family" reasons the compiler
ends up using altsyncram:

lpm_ram_dq:ram
__altram:sram
____altsyncram:ram_block

The error message doesn't say which are the
missing resources. I guess the ram needs to be
a dual port one. I use one port and the Editor
uses the other. If i disable ENABLE_RUNTIME_MOD
i get a single port. I thought the other port is left
unused, but now i'm not sure the chain:

lpm_ram_dq->altram->altsyncram

sets up for a dual port usage at all.

Even though i declare a single port, i thought
the synth adds the second one as soon as it
realizes the Runtime Mod is enabled. Altsyncram
has Dual Port, after all.

Or is the issue about something else?



Article: 123946
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 7 Sep 2007 09:53:49 -0400
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fbr7ac$l83$1@aioe.org...
> "MM" <mbmsv@yahoo.com> wrote in message
> How about not generating the clocks, but clock enables from the 210MHz 
> signal? For example, to make the ~96.55MHz signal:-
>

Hi Symon,

My original design did use 70 MHz clock enable. When I needed to change it 
(for a different reason) I decided in favour of multiple clocks mostly 
because I had a lot of trouble meeting timing constraints in the original 
design and had to resort to specifying multi-cycle paths... I do realize 
however that having multiple clocks create other problems! Anyways, for now 
my clocks seem to work fine, so I will probably stick to them for a while, 
that is until I run into metastability somewhere :)

Thanks,
/Mikhail 



Article: 123947
Subject: Re: DDR Simulation via MIG
From: motty <mottoblatto@yahoo.com>
Date: Fri, 07 Sep 2007 06:57:38 -0700
Links: << >>  << T >>  << A >>
The problem is in the testbench file that the MIG creates.  It only
instantiates and connects 1 memory IC.  Thus from a module
perspective, there is a lot missing.  I instantiated 3 more IC's to
get the thing working.

Xilinx should explicitly state that info in the readme file.  I didn't
pick up on it from that file or the MIG user guide..but maybe I'm
dense.


Article: 123948
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Fri, 07 Sep 2007 14:06:42 -0000
Links: << >>  << T >>  << A >>
On Sep 7, 8:14 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Paul Keinanen wrote:
>
> (snip)
>
> > If the OP required only something dedicated point to point
> > connectivity, why bother with the IP wrapper, just send raw Ethernet
> > frames with MAC addressing ?
>
> You could, but sending UDP isn't that much harder.  If you really want
> to simplify it, put the destination MAC address in as a constant

This is exactly why direct MAC communication is undesirable here.
Tying the sender to the receiver's MAC address as a constant isn't
good engineering.

> (saves doing ARP, but ARP could also be done in external software
> and the result written to the FPGA).

Indeed. ARP needs to be done only once in a while anyway, so it can be
done by a slow software program.

> The next complication is
> generating the CRC for UDP, but that is optional.  The ethernet
> CRC has to be generated in either case.

CRC generation in FPGAs is blazing fast, so I don't really see a
problem here.

Eli


Article: 123949
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 07 Sep 2007 14:36:46 -0000
Links: << >>  << T >>  << A >>
On Sep 7, 8:53 am, "MM" <mb...@yahoo.com> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:fbr7ac$l83$1@aioe.org...
>
> > "MM" <mb...@yahoo.com> wrote in message
> > How about not generating the clocks, but clock enables from the 210MHz
> > signal? For example, to make the ~96.55MHz signal:-
>
> Hi Symon,
>
> My original design did use 70 MHz clock enable. When I needed to change it
> (for a different reason) I decided in favour of multiple clocks mostly
> because I had a lot of trouble meeting timing constraints in the original
> design and had to resort to specifying multi-cycle paths... I do realize
> however that having multiple clocks create other problems! Anyways, for now
> my clocks seem to work fine, so I will probably stick to them for a while,
> that is until I run into metastability somewhere :)
>
> Thanks,
> /Mikhail


I would recommend against using the DCMs they way you are now.  I made
the same mistake of using the FX output of one DCM to feed others.  It
worked for quite a while, but as I added more stuff to the design, it
started to fail intermittently.  If you do not want to use clock
enables as Symon suggested, consider using logic to generate the
clocks.  As long as you can tolerate the jitter, you can take the
output of the clock generator and buffer it with a BUFG to distribute
it.

Regards,

John McCaskill
www.fastertechnology.com




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