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
"kislo" <kislo02@student.sdu.dk> wrote in message news:bbc75873-123f-4c0e-815b-ddcadae59385@b1g2000hsg.googlegroups.com... > In the IBIS model i can find the package parasitics R_pkg, L_pkg and > C_pkg ... but what does these values represent? is it the total > parasitics of the entire pins of the package? is it for single pins of > the package? http://vhdl.org/pub/ibis/ver4.2/ver4_2.pdfArticle: 132051
I have a design that consists in part, of the DDR interface from the ML403 board, but with two of these 1Gb DDR parts: http://www.micron.com/products/partdetail?part=MT46V64M16P-6T%20IT instead of these 256Mb parts that were on the original ML403: http://www.micron.com/products/partdetail?part=MT46V16M16TG-6T This should increase the memory from 64MB to 256MB, as explained in the ML403 User Guide. On the PLD_DDR instance in the mhs file, I increased the row and column addresses each by 1, increased the memory space on the PLB bus by 4x, and hooked up the additional address pin in the mhs and ucf files. But memory operation is erratic - when writing several words, often all words read back as the last value written to the last word. Also, sometimes the middle bytes come back FF's. When I configure the design for the smaller memory chips, the 1Gb chips suddenly start working correctly, but of course the memory is the old 64MB size. Has anybody made the PLB_DDR design work with 1Gb chips? I tried using the MPMC, which worked - but it used an unacceptable amount of resources. I opened a webcase, but they have been little help - I'm hoping someone here has some experience/advice to share before I dive into it deeper. thanks in advance, -JeffArticle: 132052
nospam <nospam@please.invalid> writes: > Below is verilog for a decoder with position counter. It counts all states > (that is 400 counts for one revolution of a 100 line encoder). That's certainly how I've always done it. > If you don't like the LSB jittering with bounce just ignore it? That was my point. Someone complained about jitter. No matter how you do it, you're going to give up something. You can't really eliminate the jitter without causing other potential problems.Article: 132053
Peter Alfke wrote:
<snip>
>
> Is there a way to get away from "if" and "provided".
> I am looking for a watertight solution, no ifs or buts...
> Assumption:
> Horrible undefined contact bounce, but only on one of the two inputs
> at any one time.
> Keep track of rotational angle with one-quadrant resolution, never an
> accumulated error.
> Avoid the hysteresis of my suggested solution
> Peter
My apologies that I couldn't rattle this off in the original poster's
VHDL preference but the Verilog should be easy to understand even to the
untrained eye.
module
whatCouldGoWrong
( input clk
, input [1:0] quad
, output reg [7:0] count
);
reg [1:0] rQuad;
// used for an asynchronous boundary crossing
wire [1:0] binQuad = {rQuad[1],^rQuad[1:0]};
// change the quadrature input to binary
wire dir = (binQuad - count[1:0]) >> 1;
// +1 is 0, -1 is 1, +/-2 is init only
always @(posedge clk)
begin
rQuad <= quad;
if( binQuad != count[1:0] )
count <= count + (dir ? -8'h1 : +8'h1);
end
endmodule
If there is ONLY one contact bouncing, the quadrant defined by the count
LSbits will track the quadrature input LSbits. If the quadrature inputs
are vacillating between two quadrants, the binary value will also
vacillate between those same two quadrants. There is no uncertainty.
No ifs or buts.
When the system starts there is no guarantee that the quadrature inputs
and the counter will correspond to the same quadrant so the count will
adjust - even if there is an "illegal" state by being 180% out of phase
at init - by initializing to a value between -2 and +1, inclusive.
There will NEVER be an illegal state after this if only one contact
bounces; the changes will always be +/-1.
There is no hysteresis and no problems as long as the clock is faster
than the change rate plus bounce of the quadrature encoder phases.
We've taken the situation far out of where it needs to be since
quadrature encoders give us the flexibility to be so stable. If the
user wants a flag for an illegal state, just include an initial mask to
keep any initialization movement from flagging a non-problem and any
difference of +/-2 after that can flag the error.
It's possible that I've missed something fundamental but I don't believe
so. The quadrature input is keeping the same quadrant information as
the LSbits of the synchronous counter. I originally viewed the problem
as more difficult than needed because of my previous Gray counter work
for very fast prescaling which required some combinatorial tricks. No
tricks here.
- John_H
Article: 132054
John_H wrote:
> Peter Alfke wrote:
>
> module
> whatCouldGoWrong
> ( input clk
> , input [1:0] quad
> , output reg [7:0] count
> );
>
> reg [1:0] rQuad;
> // used for an asynchronous boundary crossing
>
> wire [1:0] binQuad = {rQuad[1],^rQuad[1:0]};
> // change the quadrature input to binary
>
> wire dir = (binQuad - count[1:0]) >> 1;
> // +1 is 0, -1 is 1, +/-2 is init only
>
> always @(posedge clk)
> begin
> rQuad <= quad;
> if( binQuad != count[1:0] )
> count <= count + (dir ? -8'h1 : +8'h1);
> end
>
> endmodule
Interesting code, wins a prize for fewest-lines!! :)
(to the point of terse...)
Quite Similar to my design, but I had separated out the 2 LSBs, as a
separate State-follow (ie more lines of code), in a more
divide-and-conquer code style.
Your code also compiles first-paste, but the report does not look quite
right.
It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as
count<2>.T := rQuad<1> * !count<1> + !count<0>
# !rQuad<1> + !rQuad<0> + count<1> * count<0>;
count<2>.CLK = clk; // GCK
(etc) for all higher bits
That means your code has synthesised to use
DOWN as rQuad<1>
and UP as
!rQuad<1> + !rQuad<0>
- which is not quite right, something might need a tweak ?
Up and down should clearly BOTH contain both Quad lines.
My code created this for 3rd bit in the counter.
SF_counter<0>.T := rotary_b_in * !rotary_a_in * !Follow<0> * !Follow<1>
# !rotary_b_in * !rotary_a_in * Follow<0> * Follow<1>;
SF_counter<0>.CLK = clk; // GCK
seems your version has a + !rQuad<0> is missing somehow ?
Lower 2 bits have more differences, but more is happening there.
-jg
Article: 132055Hello, I am a beginer and have a basic question. My project implemented on FPGA board (which is Spartan3E-1600 Microblaze Development Kit) includes ADC and is supposed to do some digital signal processing of an analog RF signal from 'outside world'. How I can input an analog signal to my FPGA?Article: 132056
Alan Nishioka wrote: > I am trying to write an sdio host controller. sdio is an extension to > the sd/mmc protocol used on memory cards. It is used for pda peripheral > devices, for example. > > Note that this question is about the sdio protocol, not the spi protocol > that is part of the sdio/sd/mmc specification. > > I am able to send and receive a response on the cmd line, but when I > send or request data, I never see it on the data lines. > > Specifically, cmd52 works for both read and write and I get the correct > response. But while cmd53 responds on the cmd line, I never see > activity on the data lines. > > Does anyone know what I am missing? I seem to be talking to myself, but I do that a lot anyway, so I will answer my own question. You need to enable the function to drive the data lines. Specifically, bit1 of address 0x0002 in the CCCR must be set. If you don't do this, you will be able to send and receive on the cmd line, but not on the data lines. Incidentally, opencores has several sd/mmc projects but they *all* only operate in spi mode. Alan Nishioka alan@nishioka.comArticle: 132057
On May 12, 2:53 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote: > Hello, > I am a beginer and have a basic question. > My project implemented on FPGA board (which is Spartan3E-1600 > Microblaze Development Kit) includes ADC and is supposed to do some > digital signal processing of an analog RF signal from 'outside > world'. > How I can input an analog signal to my FPGA? Hi, I don't know this board do you have a link to it description? If it is a parallel ADC you generally need to feed your ADC with your sampling clock and then you get your sample from the adc every clock cycle. An easy way to check this is to put a probe on the ADC input using chipscope and put a signal generator at the input of your ADC and then you look with your probe the signal you receive, if you inputed a a sin wave you should get a sin wave in the probe. alexisArticle: 132058
Hi ! Is Virtex 4 supported by Jbits ?Article: 132059
Hi, Virtex5 datasheet state that there is a optional configurable weak pull-up/pull-down resistor on each IOB. What is the value of that resistor? I looked at the user guide and configuration guide but could not find it. -- GoliArticle: 132060
Goli wrote: > Virtex5 datasheet state that there is a optional configurable weak > pull-up/pull-down resistor on each IOB. What is the value of that > resistor? I looked at the user guide and configuration guide but could > not find it. Take a loot at page 2 of the data sheet for DC and switching characteristics: http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 132061
> An easy way to check this is to put a probe on the ADC input > using chipscope and put a signal generator at the input of your ADC > and then you look with your probe the signal you receive, if you > inputed a a sin wave you should get a sin wave in the probe. > > alexis My problem is that I do not understand how to establish a connection between an output of signal generator (which is RF connector) and an input of ADC which is one of FPGA pins as they are physically incompatible. (As I understand one of FPGA's pins has to be assigned as an input of FPGA-based ADC.) I just guess that there are should be something else between an analog source and FPGA board, isn't it? and I would like to learn what it is.Article: 132062
Vagant wrote: > My problem is that I do not understand how to establish a connection > between an output of signal generator (which is RF connector) and an > input of ADC which is one of FPGA pins as they are physically > incompatible. If the voltage is in the range of the allowed input voltage for your ADC (take a look at the data sheet of your kit) and the frequency is not too high (I guess the ADC doesn't convert more than 1 MSPS), try a crocodile clip. Don't forget to attach the ground, too. > (As I understand one of FPGA's pins has to be assigned > as an input of FPGA-based ADC.) Usually the FPGA doesn't have an integrated ADC, but you have to assign and program it to access the external ADC. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 132063
Jim Granville wrote: <snip> > > It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as > > count<2>.T := rQuad<1> * !count<1> + !count<0> > # !rQuad<1> + !rQuad<0> + count<1> * count<0>; > count<2>.CLK = clk; // GCK > > (etc) for all higher bits <snip> remind me again, please: I thought the # was the OR operator but you have a mix of + and * mixed in there as well. Does your synth produce an enable for each register, too? Forcing an enable (count[1:0]!=quad) might clarify the operation a little from a human-readable standpoint. - John_HArticle: 132064
Once you get the simple stuff down and learn the development environment (the hardest part), I recommend, "Advanced Digital Design with the Verilog HDL" by Ciletti. The book is geared towards the lower level of digital design, but quite in-depth. ---Matthew Hicks > Hi all, > > My background is in Software Engineering C,C++,Java and Unix. I am > getting started with VHDL and Verilog. What is the good way/books/ > websites/training to get started? I have B.S. and M.S. in Computer > Engineering. Also, what is the learning curve in VHDL and Verilog? > > Please let me know. > > Thanks > JayArticle: 132065
Jim, A motivated competitor has the legal right to reverse engineer your product -- you do need to protect yourself. A patent would be nice, but often a patent is too expensive, and that may not deter a competitor. If using Virtex II, IIP, 4, or 5, I suggest the lithium coin cell battery from Ray-O-Vac, and the use of encryption. That is a minium of 15 years of battery life (to 2.0 volts), and since the key is maintained down to less than 1 volt, Ray-O-Vac is unable to extrapolate the lifetime beyond their 2 volt end of life (they said "as close to forever as you can get"). As long as their is reactive lithium in the cell, it is able to push out electrons. Set top boxes use the lithium battery solution for example (they know how to protect themselves). If using Spartan, there is no comparable encryption solution. Some customers use the 3AN (with internal prom) as they feel that has sufficient barriers to reverse engineer (no signal of the configuration appears externally). Identifying a small part of the design, and reverse engineering just that part is tough, but not unheard of. The other choice is to hide, or obscure the design as best you can: I know that the crypto community chants "there is no security in obscurity" but obscurity is used by most anyways (causes the thief to look for something easier). Obscurity is the solution favored by natural evolution (so it does work well enough ...). AustinArticle: 132066
kislo, The parasitics are the extracted RLC from the transmission lines in the package. The package specific models have a min, typ, and max value. The simulators take the RLC, and create a multi-section t-line from pi-models based on these values (as it is not an R, and L, and a C). For per pin parasitics, you disable the RLC (comment it out of the model) and replace it with the package t-line of the proper length in your simulation. Xilinx supports package maps of per pin time delay, or per pin t-line length to a package ball in 5mm 'buckets'. This length is also used by those who are designing wide buses which must arrive all at the same time. The concern is that for the highest speed buses we need to go to 1 mm resolution. Perhaps we do. In any event, if you really need the exact length, you may request this from your Xilinx FAE. AustinArticle: 132067
No, it is not. AustinArticle: 132068
http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf Table 3, page 2. Austin Goli wrote: > Hi, > Virtex5 datasheet state that there is a optional configurable weak > pull-up/pull-down resistor on each IOB. What is the value of that > resistor? I looked at the user guide and configuration guide but could > not find it. > > -- > GoliArticle: 132069
On May 10, 6:20 pm, Joseph Samson <u...@not.my.company> wrote: > Pratap wrote: > > Hi all, > > [snip] > > > Is there any method by which I can take the data values only at the > > high values of the pulse and hence all data point will be different. > > I don't have ChipScope in front of me, so this is from memory. The > trigger settings allow you to specify a number of 'windows' (I think > that's what they're called) and the number of samples per window. If > your buffer size is 1024 and you choose 512 windows, then each window > would have 2 samples. You would set the trigger to the pulse signal, and > then Chipscope would show you 512 consecutive triggers. > > --- > Joe Samson > Pixel Velocity Yes, The windows method worked....Thanks for the help... Now on each window I am taking 1 sample and I am taking 512 windows...which solves my purpose. Thanks again...:)Article: 132070
On 12 =CD=C1=CA, 16:07, Frank Buss <f...@frank-buss.de> wrote: > If the voltage is in the range of the allowed input voltage for your ADC > (take a look at the data sheet of your kit) and the frequency is not too > high (I guess the ADC doesn't convert more than 1 MSPS), try a crocodile > clip. Don't forget to attach the ground, too. > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-syst= ems.de Thank you. Using a crocodile clip should work indeed but I look for something more robust and permanent.Article: 132071
On Apr 25, 4:20 pm, BestIn...@gmail.com wrote: > I stand corrected. I should have looked at whois first. This is a > bold move to open VMM. Now the only question is why Accellera has no > listed VMM project. Because this committee is focused on defining interoperability between verification IP, not opening or standardizing the VMM.Article: 132072
"Vagant" <vladimir.v.korostelev@rambler.ru> wrote in message news:63eb6286-cf11-476b-90d2-c44e93c343c4@x35g2000hsb.googlegroups.com... > > My problem is that I do not understand how to establish a connection > between an output of signal generator (which is RF connector) and an > input of ADC which is one of FPGA pins as they are physically > incompatible. What are you talking about? There are no ADCs in Spartan-3E! You can make a delta-sigma one yourself (http://www.xilinx.com/support/documentation/ip_documentation/xps_deltasigma_adc.pdf), but I doubt you can make it run fast enough for any RF application... Usually an ADC is an external component. /MikhailArticle: 132073
John_H wrote: > Jim Granville wrote: > <snip> > >> >> It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as >> >> count<2>.T := rQuad<1> * !count<1> + !count<0> >> # !rQuad<1> + !rQuad<0> + count<1> * count<0>; >> count<2>.CLK = clk; // GCK >> >> (etc) for all higher bits > > <snip> > > remind me again, please: > I thought the # was the OR operator but you have a mix of + and * mixed > in there as well. Yes # = OR, * = AND, + = my typos (oops), as I re-ordered the terms for clarity. > > Does your synth produce an enable for each register, too? Forcing an > enable (count[1:0]!=quad) might clarify the operation a little from a > human-readable standpoint. No, strange thing is ONE direction seems plausible, but the other dirn seems wrong.... ? (This was Xilinx webpack) What does your report say ? -jgArticle: 132074
Jim Granville wrote: <snip> > It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as > > count<2>.T := rQuad<1> * !count<1> * !count<0> > # !rQuad<1> * !rQuad<0> * count<1> * count<0>; > count<2>.CLK = clk; // GCK > > (etc) for all higher bits <snip> Typos corrected, "+" changed to "*" where "*" is and while "#" is or. For the upper bits, the down count will happen when the rQuad is behind the count by 1 or 2 phases and the count[1:0] is 00 and the up count will happen when the rQuad is in front of the count by 1 phase and the count[1:0] is 11. Because the logic you're using is a toggle, the upper bits will only change when the count[1:0] is 00 and the rQuad is 10 or 11 (down) or the count[1:0] is 11 and the rQuad is 00 (up). This matches your (de-typoed) logic above. Since the count is used to judge the retained quadrant rather than a registered version of the quadrature inputs, the up/down toggle points work in nicely with the quadrant detection. - John_H
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