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
> 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. EliArticle: 123926
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. > > -jgArticle: 123927
>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
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. -- glenArticle: 123929
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. -- glenArticle: 123930
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? -- glenArticle: 123931
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. -- glenArticle: 123932
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. -- glenArticle: 123933
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.) -- glenArticle: 123934
yes the MMU function of the PowerPC is ON. RegardsArticle: 123935
Thank you very much!Article: 123936
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 SulimmaArticle: 123937
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
"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: 123939On 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. VasileArticle: 123940
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., DavidArticle: 123941
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. - BrianArticle: 123942
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
> > 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. AndrewArticle: 123944
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 AgroboticArticle: 123945
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"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, /MikhailArticle: 123947
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
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. EliArticle: 123949
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:
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