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
On 28 Apr 2004 15:09:25 +0100 (BST), Thomas Womack
<twomack@chiark.greenend.org.uk> wrote:
>Is there a better Verilog sequence for the polynomial-multiplier
>
>begin
>C[10:0] <= A[10:0] & {B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0]};
>C[11:1] <= C[11:1] ^ (A[10:0] & {B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1]});
>...
I really don't think you mean quite that. Maybe if the
assignments were blocking, instead? (always assuming you're
trying to do the whole thing in one clock cycle)
This sounds a bit nicer... it depends on the fact that
XORing with zero has no effect. Some details missing,
of course.
reg [20:0] C;
reg [10:0] A, B;
integer i;
...
C = 0;
for (i=0; i<=10; i=i+1) begin
if (B[I]) begin
C = C ^ (A << I);
end
end // for
>or should I be writing Perl to generate the rather stereotyped code above?
Maybe... not for my taste, though.
The form
A[10:0] & {B[1], B[1] ....}
is easily rewritten using a conditional expression:
B[1] ? A[10:0] : 11'b0
>What if I want a polynomial-multiplier of user-definable width?
I think the version I offered could easily be modified
so that it's parameterised.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 69151
If you just want to avoid the manual replication in the concatenated vector,
use the replicate {{ }}:
C[10:0] <= ( A[10:0] & {11{B[0]}} );
C[11:1] <= ( A[10:0] & {11{B[1]}} ) ^ C[11:1];
or use the conditional operator
C[10:0] <= ( B[0] ? A[10:0] : 11'h000 );
C[11:1] <= ( B[1] ? A[10:0] : 11'h000 ) ^ C[11:1];
"Thomas Womack" <twomack@chiark.greenend.org.uk> wrote in message
news:Ptb*f7+iq@news.chiark.greenend.org.uk...
> Is there a better Verilog sequence for the polynomial-multiplier
>
> begin
> C[10:0] <= A[10:0] &
{B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0]};
> C[11:1] <= C[11:1] ^ (A[10:0] &
{B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1],B[1]});
> ...
>
> C[20:10] <= ...
> end
>
> or should I be writing Perl to generate the rather stereotyped code above?
>
> What if I want a polynomial-multiplier of user-definable width?
>
> Tom
Article: 69152
Greetings:
I am learning Verilog from the book "A Verilog Primer 2nd. ed." by J.
Bhasker.
Here's my crack at a digital one shot. It works fine, or course, since
I have already used it in real hardware. But I am interested in
pointers on coding style or any other comments people might like to make:
Note: some of the delays and the initial statement are for making the
functional simulation work, but I know they get ignored during synthesis.
----------------------------------------------------------
/* This module implements a digital one-shot with N-bit resolution.
Ports:
Trig_in rising edge causes output pulse to begin
Out positive going output pulse appears here
Clk_in user must supply a clock here
Delay user must supply an N-bit value here for the number of
clock periods to delay
How it works:
An N-bit counter gets clocked all the time by the incoming clock signal.
A D-flop latches the input trigger and also enables the counter. The
output pulse is taken from the D-flop Q output. Thus the leading edge
of the output pulse is synchronous with the trigger edge. But the
trailing edge of the output will be synchronous with the clock.
At the end of a delay cycle, the D-flop Q output falls and resets the
counter, preparing it to count again. An incoming trigger pulse sets
the D-flop, causing Q to rise, releasing the CLR of the counter. When
the count reaches the Delay value, the D-flop is reset. This causes the
Q to fall again, clearing and holding the counter until the next trigger.
*/
module DelayNbit(Trig_in, Out, Clk_in, Delay);
parameter NUM_BITS = 8; // This sets the default number of bits of
counter resolution
input Trig_in, Clk_in;
input [NUM_BITS-1:0] Delay;
output Out;
wire Trig_in, Clk_in;
wire [NUM_BITS-1:0] Delay;
reg Out;
wire Clr_ff; // flip-flop asynchronous clear input
reg [NUM_BITS-1:0] Q_c; // register for N-bit counter
/* BEGIN behavioral model of the D flip-flop with asynchronous clear,
adapted from Xilinx <lib.pdf>:
*/
initial
Out = 0;
always @ ( posedge Trig_in or posedge Clr_ff )
begin
if ( Clr_ff == 1 )
#4 Out <= 0;
else
#4 Out <= 1; // we tie the D input to logical high
end
// END of D flip-flop behavioral model
/* BEGIN behavioral model of N-bit counter with asynchronous clear,
adapted from Xilinx <lib.pdf> :
*/
always @ ( posedge Clk_in or negedge Out )
begin
if ( !Out )
#4 Q_c <= 0;
else
#4 Q_c <= Q_c + 1;
end
// END of N-bit counter behavioral model
assign #4 Clr_ff = ( Q_c == Delay ); /* this compares the count with
Delay, and when equal
resets the flip-flop. */
endmodule
----------------------------------------------------------
Thanks for input.
Good day!
--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov
Article: 69153You need a PLL where both frequencies are divided to 8kHz (1544k/193=8k, 2048k/256=8k) to feed the phase comparator. That is unless you want to go to multiply your input clock a 395.264 MHz (1.544M*256, 2.048M*193) and have a 50% +/-0.25% duty cycle on the 2.048 MHz clock. Standard PLL designs are typically divided to a low reference frequency and require a stable VCO (or probably VCXO in your case) though there are other techniques out there. "Martin" <visepp@yahoo.de> wrote in message news:2eca51ca.0404280548.231b65d0@posting.google.com... > Hi, > > I'm using a PLL (HCT9046 from Philips) and I should convert > a T1 Clock (1.544MHz) to an frequency of 2.048MHz. > > This is normal possible with an PLL. What I should have is a Divider, > which divides my 2.048MHz to a frequency of 1.544MHz. > > Does anybody know how to do this? > The output clock should have if possible a duty cylce of 50% > > > Best regards > MartinArticle: 69154
Hello, I am a computer engineering student and I am looking to do a project which will require a FPGA or CPLD. I will need something with > 70 general IO pins. I am looking for a development board that will give me an expansion port to plug it into my project. I want something less than $100 perferably less than $50. I am currently considering the CPLD design kit from XILINX which has XC2C256-7TQ144 CoolRunner-II CPLD and XC9572XL-10VQ44 CPLD on it as it seems to be a good starter package. Are there other quick dirty solutions that will allow me to easily program a device and integrate it with my project? I do not need something that has tons of LEDS and pushbuttons and tons of extra proto space. Thank You Josiah VivonaArticle: 69155
On Wed, 28 Apr 2004 08:29:38 -0700, Chris Carlen
<crcarle@BOGUS.sandia.gov> wrote:
> I am interested in
> pointers on coding style or any other
> comments people might like to make:
Interesting...
You've coded two standard clocked "always" blocks - fine.
You've declared all your inputs as "wire". That's not
necessary, but it's a good idea.
I have a few issues with the cosmetics of your code -
in particular I don't like using /*...*/ block
comments, because they don't nest and you can easily
get yourself into trouble with them; but that's
a matter of style choice.
>Note: some of the delays and the initial statement are for making the
>functional simulation work, but I know they get ignored during synthesis.
You don't *need* the delays for functional simulation, because
nonblocking (<=) assignment introduces a "delta" delay anyhow;
but it can often be nicer to *see* the delays on a waveform
viewer. Perhaps you could consider parameterising the delays,
or using `define so it's easy to switch them in or out
according to what you're doing with the model...
// Remove "#4" from this line if you don't want delays...
`define `FF_DELAY #4
...
always @(...)
Q <= `FF_DELAY D+1;
... you get the idea.
But my main concerns relate to...
> Here's my crack at a digital one shot. It works fine,
> or course, since I have already used it in real
> hardware.
hmmmm.... the design has some "interesting" non-synchronous
features that don't sit comfortably in FPGAs - I guess you're
targeting Xilinx, from your comments - it would be very
interesting to know your reasons for being confident about
its reliability. I *think* I understand that it's OK to
remove the reset (!Out) on Q_c asynchronously, although it
could easily be subverted by a sufficiently fast Clk_in.
I also am nervous of the clearing of Out by a pulse
which is immediately terminated by Out clearing...
Generally it's very dangerous to use the asynchronous
resets of FPGA flip-flops for anything other than
startup initialisation. Timing analysis of the reset
paths into a FF is vexatious at best.
Finally, from an FPGA point of view, these timeout
counters are usually more compact if you use the trigger
to load the counter with the delay value, then count
down to zero; equality comparison with a constant is
much cheaper than equality comparison with a variable.
However, that strategy would (I think) demand a fully
synchronised design.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 69156hey, i'm having some problems with a timing constraint. let's say i have 1 top component that consists of 2 subcomponents. and one of those subcomponents needs a timing constraint like clk period = 100Mhz and the otherone doesn't (if i do it gives me some timing errors). so i thought i'll add the attribute period : string; attribute period of clk : signal is "100 Mhz"; and i also added attribute maxdelay: string attribute maxdelay of reset : signal is "10 ns"; in vhdl. but when i do that the compiler (xst) seems to find the maxdelay constraint but not the period constraint? how come? => when i look at the synthesize report it recognizes the constraint but in place and route it doesn't? why does this happen? i really don't have a clue? should i enter the constraint in the UCF? or in the XCF (and how do you make XCF?) ... thanks for your help, kind regards, yttriumArticle: 69157
"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message news:c6oil102ndg@news3.newsguy.com... > Greetings: > > I am learning Verilog from the book "A Verilog Primer 2nd. ed." by J. > Bhasker. > > Here's my crack at a digital one shot. It works fine, or course, since > I have already used it in real hardware. But I am interested in > pointers on coding style or any other comments people might like to make: [snip] > always @ ( posedge Trig_in or posedge Clr_ff ) > begin > if ( Clr_ff == 1 ) > #4 Out <= 0; > else > #4 Out <= 1; // we tie the D input to logical high > end I have a personal preference to improve readability of my own code. I have trouble digesting code that's sprawled over several pages so I try to compress things vertically when I can without crowding the code too much. When an always block has just one construct - an if/else for async set/reset, for instance - the begin/end is superfluous. Indentation keeps my visual clues telling me what belongs in one begin/end construct or stands alone as one statement. When if/else constructs have short assignments, I like to do those in-line if the code isn't crowded. I'd code the block above as: always @ ( posedge Trig_in or posedge Clr_ff ) if ( Clr_ff == 1 ) #4 Out <= 0; else #4 Out <= 1; If you're viewing with the default proportianal-spaced font, however, the "cleanliness" of the code is lost. All my code authoring is done in fixed-width fonts allowing a clean alignment. A complex always block usually takes up a half screen or less on my system allowing a chance to study what's going on just by staring at it long enough. But other people like more stuff & structure. A note on my indenting: always @(... single <= statement; ^^ indentation always @(... begin multiple; statements; end ^^ indentation of statements, not of begin/end keywords Again, personal preference.Article: 69158
There are a number of standard off the shelf components to do this, Check out Dallas Semiconductor (now Maxim), Cypress Semi, ICST, etc. Far too easy and two cheap single component solutions to do it on your own. Re-inventing the wheel is not a good career move. Austin John_H wrote: > You need a PLL where both frequencies are divided to 8kHz (1544k/193=8k, > 2048k/256=8k) to feed the phase comparator. That is unless you want to go > to multiply your input clock a 395.264 MHz (1.544M*256, 2.048M*193) and have > a 50% +/-0.25% duty cycle on the 2.048 MHz clock. > > Standard PLL designs are typically divided to a low reference frequency and > require a stable VCO (or probably VCXO in your case) though there are other > techniques out there. > > > "Martin" <visepp@yahoo.de> wrote in message > news:2eca51ca.0404280548.231b65d0@posting.google.com... > >>Hi, >> >>I'm using a PLL (HCT9046 from Philips) and I should convert >>a T1 Clock (1.544MHz) to an frequency of 2.048MHz. >> >>This is normal possible with an PLL. What I should have is a Divider, >>which divides my 2.048MHz to a frequency of 1.544MHz. >> >>Does anybody know how to do this? >>The output clock should have if possible a duty cylce of 50% >> >> >>Best regards >>Martin > > >Article: 69159
"arkaitz" <arkagaz@yahoo.com> escribió en el mensaje news:c1408b8c.0404270111.5597b66a@posting.google.com... > Hi Paris, > > First of all, thanks for answering to my message. > I'll try to answer to all of your questions. > > > hadnt you posted this problem before? > > Yes and no. The post I wrote before had to do a lot with this one but > now I think that the problem comes from another source. > > > > what do you mean by "synchronized"? to what? besides "input" should be > > stable before (and after) the clock edge, they shouldnt change at the same > > time (if that's what you meant with "synchronised") > > and i would have thought that a glitch is what you're getting with those "0 > > ps" pulses > > The "input" signal is an asynchronous input port and it must be > synched before I use in my design, just to avoid metastability and > glitches. Even if its asynchronous it's active during several clock > hundreds of clock cycles. Here you are the synch: if you want to sync to avoid metastability, maybe you could check out http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > entity top > port ( > ... > in : in std_logic; > ... > ); > end top; > > architecture arch of top is > ... > signal input : std_logic; > signal i_filter : std_logic_vector(1 downto 0); > ... > begin > process ( rst, clk ) > begin > if ( rst = '1' ) then > i_filter <= (others => '0'); > elsif ( clk'event and clk = '1' ) then > i_filter(0) <= in; > i_filter(1) <= i_filter(0); > end if; > end process; > > input <= i_filter(1); > > > you could write it otherwise, like > > > > elsif ( clk_60'event and clk = '1' ) then > > if ( re_edge = '1') then > > out <= '0'; > > elsif ( input = '1' ) then > > out <= '1'; > > end if; > > end if; > > yes, that's true, but the result would be the same. > > no it wouldnt, cause in your design, there's a problem is "re_edge" and "input" are both high this one only if re_edge is not high, the second statement (the elsif) would be executed, in your code, both if's will always execute > > dont you think you should correct that? do you think that's a good sign? > > besides that's completely normal from your "re_edge <= not aux and input" > > even on real logic that pulse wouldnt be large, how large do you want it to > > be? and even then it should arrive a bit later than the clk60 edge, so you'd > > probably miss it anyway > > just a clock period wide to allow to use it as a clock enable signal. > I have done used this code several time and it has always worked. > you've used this same code before and it worked and now it's not working? > > > I don't know certainly why, but I believe that it can be because I use > > > the DLL. > > > what, the 0 ps pulse is due to the DLL? or "out" not going low? > > both, because one comes from the other, I mean, the "out" doesn't go > low because the rising edge signal is not detected correctly. > > > and what do you want? > > just to know if somebody has ever got any trouble using two different > clock domains and when both clocks are provided by the DLL. > > My reflexion: it might work in physically but I would like ensure with > functional simulation before implementing the design. > then you should get rid of the 0ps glitch caused by "re_edge <= not aux and input;" > > why are you synchronizing the reset of the second FF with a clock that's > > running slower than this FF clock? > > Because that's requirement of my design. I know that I could do with > some clock enables but the DLL might be necessary in order to improve > the required max. frequency. > > > if what you want is to reset your second FF on a rising_edge of input, then > > i wouldnt do its reset "synchronous" > > do you mean using asynchronous signals in a syncronous design? I don't > think that'd be a great idea. > but i thought that's what you were doing, aint you trying to avoid the metastability caused by an async signal entering your synchronous system? anyway, the link might help you, as it contains code similar to yours (i think) > > why dont you use a "digital oneshot" clocked by the fastest clock (so that > > your output stays low or high just for one cycle), that could be a FSM that > > would wait for a high (that'd be the rising_edge of input) value of input, > > and then wait for it to become low to start waiting again. > > That's another posibility but it might use more resources than what > I've done. > > > Thanks a lot for your patience, > > Arkaitz > ------------------------------- > Ikerlan > Electronics Area > Pº J. M. Arizmendiarrieta, 2 > 20500 Arrasate (Gipuzkoa) > -------------------------------Article: 69160
You should take a look at your Xilinx Library Guide installed
in the doc directory tree.Name of the file is lib.pdf. The RAMB4
section describes the various Block RAM configurations, as well
as examples on initialization.
Reason that I mention this document, is it is excellant reference for
learning all primitives within various Xilinx FPGA families.
Here is some sample code
(Note, the INIT constants end at INIT_0F for a 4K block RAM) :
defparam pin_lookup_512x8.INIT_00 =
256'h3817391841204215321133123514360926052706290830034745440123022448;
defparam pin_lookup_512x8.INIT_01 =
256'h0000000000000000000000000000000000000000000000506261575654535121;
defparam pin_lookup_512x8.INIT_02 =
256'h4120421732333435363738310325262728293024454443220123024650494847;
defparam pin_lookup_512x8.INIT_03 =
256'h0000000000000000000000000000000000000051585756555453522139184019;
RAMB4_S8 pin_lookup_512x8 (
.CLK (cr_clk_100mhz),
.RST (cr_100m_rst),
.WE (1'b0),
.EN (1'b1),
.ADDR ({1'b0, err_raw_val}),
.DI (8'h00),
.DO (bcd_pin_convert)
);
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc. (Colorado Based Xilinx Consultant)
email : jretta@rtc-inc.com
web : www.rtc-inc.com
"Arlen" <a_cox@pacific.edu> wrote in message
news:ee83f7d.-1@WebX.sUN8CHnE...
I have a Xilinx Spartan IIE device and it has built in block rams that I
would like to use for effectively a ROM design.
All the documentation that I can find that Xilinx provides seems to be
rather old (2000-2001) and thus doesn't work on the current tools (Webpack
6.2). Does anyone know how to specifiy block ram initialization values in
verilog using Webpack 6.2?
Thanks,
Arlen
Article: 69161Jonathan Bromley wrote: > On Wed, 28 Apr 2004 08:29:38 -0700, Chris Carlen > <crcarle@BOGUS.sandia.gov> wrote: > > >>I am interested in >>pointers on coding style or any other >>comments people might like to make: > > > Interesting... > > You've coded two standard clocked "always" blocks - fine. > > You've declared all your inputs as "wire". That's not > necessary, but it's a good idea. > > I have a few issues with the cosmetics of your code - > in particular I don't like using /*...*/ block > comments, because they don't nest and you can easily > get yourself into trouble with them; but that's > a matter of style choice. Ok. > You don't *need* the delays for functional simulation, because > nonblocking (<=) assignment introduces a "delta" delay anyhow; > but it can often be nicer to *see* the delays on a waveform > viewer. Yes, I discovered this, and simply wanted to make it look nicer so put in the delays, also knowing the synthesis would simply whine then ignore them. > Perhaps you could consider parameterising the delays, > or using `define so it's easy to switch them in or out > according to what you're doing with the model... > > // Remove "#4" from this line if you don't want delays... > `define `FF_DELAY #4 > ... > > always @(...) > Q <= `FF_DELAY D+1; > > ... you get the idea. Maybe parameterizing is a good idea, because I was hoping to figure out a way to have the delays active dependent upon who was instantiating the module, which can be controlled by using "module instance parameter value assignment" or defparam. But there is still the question about how to direct conditional compilation of statements in an instantiated module from the instantiating module. Ie., I'd like to have an `ifdef to conditionally compile for instance the initial statement which is supoerfluous to implementation, but not for simulation. Or I'd like to not have to edit the module to change the defines, but simply adjust them from the top level. I don't quite know how this works yet. I'll have to do some experimenting. > But my main concerns relate to... > > >>Here's my crack at a digital one shot. It works fine, >>or course, since I have already used it in real >>hardware. > > > hmmmm.... the design has some "interesting" non-synchronous > features that don't sit comfortably in FPGAs - I guess you're > targeting Xilinx, from your comments - it would be very > interesting to know your reasons for being confident about > its reliability. Good question. Actually I suppose I can't be certain when implementing in a PLD. I am using XPLA3 CPLDs at the moment. I am confident in the circuit implemented in discrete logic, of course, because one can depend on the propagation delays to be sure that the main flip-flop reset remains true until it is removed after propagating the counter reset through the flip-flop, counter, and comparator. But there are indeed questions about what goes on in the CPLD. Perhaps it would only be 100% safe if I coded it structurally and gate level, and used "WYSIWYG" mode of the implementation options. > I *think* I understand that it's OK to > remove the reset (!Out) on Q_c asynchronously, although it > could easily be subverted by a sufficiently fast Clk_in. I hadn't thought about what could go wrong here with the clock being close to the reset. I got the basic circuit from Art of Electronics, 2nd. ed., page 523. Are you thinking it is possible for some of the flops in the counter to interpret a clock edge close to the release of reset as happening before the reset removal, but some of the other flops interpreting it as not happening before the reset removal? One can envision this happening due to propagation delays over physical wires. But perhaps in the case of starting from zero, this isn't an issue. I'd have to think more carefully about the guts of the counter to be sure about this. > I also am nervous of the clearing of Out by a pulse > which is immediately terminated by Out clearing... Yeah, I addressed this above, but what do you think of my analysis? First tell me (since you are probably a more experienced logic designer in general) how comfortable you would be with the design in discrete logic? Then in a PLD (considering my thoughts above)? > Generally it's very dangerous to use the asynchronous > resets of FPGA flip-flops for anything other than > startup initialisation. Timing analysis of the reset > paths into a FF is vexatious at best. > > Finally, from an FPGA point of view, these timeout > counters are usually more compact if you use the trigger > to load the counter with the delay value, then count > down to zero; equality comparison with a constant is > much cheaper than equality comparison with a variable. > However, that strategy would (I think) demand a fully > synchronised design. Well that's probably safer. I am becomming very interested in digital delay generation and the question of how to reduce jitter. Of course, my design has no leading edge jitter, and has up to one clock period of trailing edge jitter. A fully synchronous design would do what? I suppose there would be synchronization jitter on the leading edge (the trigger edge), but then the time would be without jitter. There has to be jitter somewhere. Ok, thanks for the input. Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 69162
Thomas Womack <twomack@chiark.greenend.org.uk> writes:
> Is there a better Verilog sequence for the polynomial-multiplier
>
> begin
> C[10:0] <= A[10:0] & {B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0],B[0]};
C[10:0] <= A[10:0] & {11{B[0]}};
is a shorter way of writing this expression.
Petter
--
A: Because it messes up 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: 69163Dear All, VHDL / Verilog circuits work in 1-V still correct? I want to combine 1-V analog circuits and VHDL circuits.. Thanks Boki.Article: 69164
Which is why I stated that if the LO is a multiple of your
input sample rate.... It should have read if the input sample rate is an
INTEGER multiple of the LO.
Kevin Neilson wrote:
> Ray,
> I've seen that idea presented before but I don't think I can combine
> mixing/filtering in my case because I'm using the IF mixer to do carrier
> synchronization so I need to be able to precisely control the LO with an
> NCO.
> -Kevin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69165
Depends on the depth. For small ranges in depth, the SRL16 is more efficient than RAM based.
john jakson wrote:
> I'll be adding FFed srls later on when the dust has settled. perhaps I
> should look at dynamic too for queues, although ram based will
> probably give me about same cost/perf/area
>
> regards
>
> johnjakson_usa_com
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69166Quick question... I've been using a Virtex-E fpga on a development board that provides jumpers to connect or disconnect Vcco for each I/O bank. Some of my inputs are LVDS, and one of my signal sources has LVDS output that swings up as high as ~2.4V at the highest. On one of my last test runs I accidentally left the Vcco jumper uninstalled for the IO bank that this device was connected to, meaning that Vcco for that bank was left floating. To make a long story short, much current was drawn, and now (probing the FPGA pins directly) Vcco for that I/O bank appears to be shorted to ground inside the chip package(~1.5 ohms from Vcco pin to Gnd pin). To anyone out there who's familiar with Xilinx hardware, would the mistake I made above (no Vcco for a ~2.4V input LVDS signal) have caused the IO bank to become damaged? I'd just like some confirmation that this is the cause, before I power up the FPGA board and fry another IO bank...Article: 69167
pelletie@caltech.edu (BJP) wrote in message news:<2107fbac.0404271452.70eb7e87@posting.google.com>... > I'm using Quartus II 2.2 with service pack 2 and SoPC Builder 2.7 but > when generating the system, I get a number of "grep: not found" > errors. I checked the Altera website but I couldn't find anything. > Has anyone had similar problems/know why these errors are occuring? > Please CC any replies to this group to me at pelletie@caltech.edu. > Thanks! A more detailed report is as follows: > Hi, In addition to Pete's & Petter's comments: The #1 cause for this type of error in the past (barring some issue with the installation simply not completing successfully) was having SOPC Builder installed (with its private Cygwin installation) when your system already had a Cygwin distribution installed somewhere else. Not-supporting multiple Cygwin installations was a limitation of SOPC Builder/Nios kits that went away when SOPC Builder 3.02 was released (SOPC Builder now comes with Quartus, independent of the Nios kit). In this release, several changes were made that now allow a separate install of the Cygwin/GNUPro tools to be installed on the PC alongside SOPC Builder. If at all possible I recommend moving up to the latest Quartus II/SOPC Builder release. Of course, if this is not an option to you, (assuming that the problem is multiple Cygwin installations) you will have to remove the other Cygwin installation from your system. Regards, Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 69168
I am using the Xilinx EDK to perform simulations of the embedded
PowerPC on a V2Pro. I have had success using simply the EDK with
Modelsim but when I change the flow to the ISE as an embedded project-
I am having trouble getting the boot ROM to be read in as a
configuration in Modelsim.
The trouble has to do with assigning the blockRAM configurations to
the blockmemories once I wrapped the system_stub in a testbench. I
was able to get this all to work with ISE when I did not embed the
processor, but once it is embedded- the blockRAM moves a level down in
the heirarchy and then the configuration statement does not compile.
My understanding in VHDL is it is like this.... (I am improvising from
memory here)
configuration name of testbenchname is
for behavior -- arch name
for uut: system_stub -- unit under test
for STRUCUTRE -- arch of system_stub
for system_i: system -- declared system
for structure
for all: blockram_types: use work.blockram_conf;
bunch of end fors and end of configuration
I stole this from the system_init file and added my new levels of
heirarchy.
It complains to me that system is not a valid component- but in the
work directory I see it there clear as day. Is there a limit to how
far down in the heirarchy you can assign configurations? I do not
believe so. I tried making multiple level configurations and have had
no luck either.
If I blow this away- the PowerPC fetches from FFFFFFC and gets zero
back. When done properly, it fetches the first opcode and I am off an
running.
Thanks,
MS
Article: 69169On Thu, 29 Apr 2004 04:03:27 +0800, Boki wrote: > Dear All, > > VHDL / Verilog circuits work in 1-V still correct? > > I want to combine 1-V analog circuits and VHDL circuits.. > > Thanks > > Boki. verilog requires at least 1.2-V, VHDL cannot determine transistor parameters.Article: 69170
If your wanting to convert E1 to T1 (as it sounds like). Check out the IDT SuperJET. It converts the clocks and the data both at the same time :-) so you've got a framer, LIU and clock gen all in one chip! Simon "Austin Lesea" <austin@xilinx.com> wrote in message news:c6orap$1u21@cliff.xsj.xilinx.com... > There are a number of standard off the shelf components to do this, > > Check out Dallas Semiconductor (now Maxim), Cypress Semi, ICST, etc. > > Far too easy and two cheap single component solutions to do it on your own. > > Re-inventing the wheel is not a good career move. > > Austin > > John_H wrote: > > You need a PLL where both frequencies are divided to 8kHz (1544k/193=8k, > > 2048k/256=8k) to feed the phase comparator. That is unless you want to go > > to multiply your input clock a 395.264 MHz (1.544M*256, 2.048M*193) and have > > a 50% +/-0.25% duty cycle on the 2.048 MHz clock. > > > > Standard PLL designs are typically divided to a low reference frequency and > > require a stable VCO (or probably VCXO in your case) though there are other > > techniques out there. > > > > > > "Martin" <visepp@yahoo.de> wrote in message > > news:2eca51ca.0404280548.231b65d0@posting.google.com... > > > >>Hi, > >> > >>I'm using a PLL (HCT9046 from Philips) and I should convert > >>a T1 Clock (1.544MHz) to an frequency of 2.048MHz. > >> > >>This is normal possible with an PLL. What I should have is a Divider, > >>which divides my 2.048MHz to a frequency of 1.544MHz. > >> > >>Does anybody know how to do this? > >>The output clock should have if possible a duty cylce of 50% > >> > >> > >>Best regards > >>Martin > > > > > >Article: 69171
On Wed, 28 Apr 2004 11:37:22 -0700, Chris Carlen <crcarle@BOGUS.sandia.gov> wrote: [...] >But there is still the question about how to direct conditional >compilation of statements in an instantiated module from the >instantiating module. Ie., I'd like to have an `ifdef to conditionally >compile for instance the initial statement which is supoerfluous to >implementation, but not for simulation. Or I'd like to not have to edit >the module to change the defines, but simply adjust them from the top >level. I don't quite know how this works yet. I'll have to do some >experimenting. `define is global to a Verilog compilation, and therefore cannot be controlled instance-by-instance. There's no way to conditionalise compilation instance-by-instance in standard Verilog, but if your tools support Verilog-2001 (not a done deal by any means) then you can use "generate...if" to conditionalise some code based on the value of a parameter, which of course can be pushed down into an instance from its parent. [...] >> I *think* I understand that it's OK to >> remove the reset (!Out) on Q_c asynchronously, although it >> could easily be subverted by a sufficiently fast Clk_in. > >I hadn't thought about what could go wrong here with the clock being >close to the reset. I got the basic circuit from Art of Electronics, >2nd. ed., page 523. If it's in AoE it *must* be good :-) > Are you thinking it is possible for some of the >flops in the counter to interpret a clock edge close to the release of >reset as happening before the reset removal, but some of the other flops >interpreting it as not happening before the reset removal? Exactly so. In general, it is unsafe for an asynchronous signal to influence more than one FF. The jargon is "input hazard". > One can >envision this happening due to propagation delays over physical wires. >But perhaps in the case of starting from zero, this isn't an issue. This is indeed the case. If the counter is held at zero, then only the very first flip-flop can be affected by the first clock after reset is removed; so the timing of reset w.r.t. clock doesn't matter (except that you might get metastability on the LSB counter bit, but that's another story). However, if you are trying to clock the counter very fast, it's just conceivable that the skew on Reset between bit 0 and bit 1 of the counter is greater than one clock period; in this case, it's just possible that the counter could successfully increment from 0 to 1, but the next bit is still held in reset by the time the NEXT clock arrives - so the counter goes back to zero again. However, this is very unlikely because the synth tools will surely lay out the counter so that its FFs are rather close together (so that it can use the ripple carry chain) and therefore the reset distribution skew is likely to be quite small. So don't worry, it's just me being paranoid as usual. >> I also am nervous of the clearing of Out by a pulse >> which is immediately terminated by Out clearing... > >Yeah, I addressed this above, but what do you think of my analysis? I think it's OK. Out is held in a FF. I think the design is a reliable asynchronous state machine, but when I said "nervous" I meant it - these things are hard to analyze, and it's very easy to screw up by extrapolating from a working design to a slightly different one that fails horribly, usually just after shipment. >Well that's probably safer. I am becomming very interested in digital >delay generation and the question of how to reduce jitter. Of course, >my design has no leading edge jitter, and has up to one clock period of >trailing edge jitter. A fully synchronous design would do what? I >suppose there would be synchronization jitter on the leading edge (the >trigger edge), but then the time would be without jitter. There has to >be jitter somewhere. Sure. A fully synch design has -0/+1 "jitter" both at the start and at the end, I think. No escape. (It's not "jitter" in the usual sense, rather "quantization error", but I guess that depends on what you're trying to do with the resulting signal). OTOH you should trawl through the last few months' comp.arch.fpga archives and take a look at what Peter Alfke and others have had to say about using polyphase clocks for very high resolution time measurements. The Xilinx DLLs make all sorts of interesting things possible. I haven't followed that discussion in detail, but it sounds like a lot of fun. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 69172
Hi,
If you compile the system_init file into "work", you can use the
configuration specified in the file directly.
A configuration can use another configuration.
ex.
I have created a testbench "system_tb" for the system generated from XPS:
In my configuration statement I have this:
configuration tb_cfg of system_tb is
for VHDL_TEST
for all : system use configuration work.system_conf;
end for;
end for;
end tb_cfg;
You should be able to do this for your system:
configuration conf_name of testbenchname is
for testbench_arch
for all : system_stub use configuration work.system_conf
end for;
end for;
end conf_name;
MS wrote:
>I am using the Xilinx EDK to perform simulations of the embedded
>PowerPC on a V2Pro. I have had success using simply the EDK with
>Modelsim but when I change the flow to the ISE as an embedded project-
>I am having trouble getting the boot ROM to be read in as a
>configuration in Modelsim.
>
>The trouble has to do with assigning the blockRAM configurations to
>the blockmemories once I wrapped the system_stub in a testbench. I
>was able to get this all to work with ISE when I did not embed the
>processor, but once it is embedded- the blockRAM moves a level down in
>the heirarchy and then the configuration statement does not compile.
>My understanding in VHDL is it is like this.... (I am improvising from
>memory here)
>
>configuration name of testbenchname is
> for behavior -- arch name
> for uut: system_stub -- unit under test
> for STRUCUTRE -- arch of system_stub
> for system_i: system -- declared system
> for structure
> for all: blockram_types: use work.blockram_conf;
>bunch of end fors and end of configuration
>
>I stole this from the system_init file and added my new levels of
>heirarchy.
>
>It complains to me that system is not a valid component- but in the
>work directory I see it there clear as day. Is there a limit to how
>far down in the heirarchy you can assign configurations? I do not
>believe so. I tried making multiple level configurations and have had
>no luck either.
>
>If I blow this away- the PowerPC fetches from FFFFFFC and gets zero
>back. When done properly, it fetches the first opcode and I am off an
>running.
>
>Thanks,
>MS
>
>
Article: 69173
Hi all,
I am trying to make a post-place & route simulation of a very simple
design.
In the "top.vhd "file there is declared an entity that contains some
generics and the architecture.
entity top is
generic(
gen1 : real := 3.0;
gen2 : std_logic;
gen3 : std_logic
);
port(
clk : in std_logic;
rst : in std_logic;
input : in std_logic;
output : out std_logic
);
end top;
When I ask ISE to simulate a PPR simulation with modelsim it generates
a file called "top_timesim.vhd". Then generates a "tb_top.tdo" where
there are some modelsim commands that compile the "top.vhd" and
"tb_top.vhd" files.
Modelsim generates a "not default binding for component top" error. I
have seen the top_timesim.vhd file and the generics of my top are
deleted!
Why can be this? Is there any way to avoid this?
Thanks in advance,
Arkaitz.
Note: I have rewriten the generics in "top_timesim.vhd" file and now
it works well.
Article: 69174cpex wrote: > Hello, > > I am a computer engineering student and I am looking to do a project which > will require a FPGA or CPLD. I will need something with > 70 general IO > pins. I am looking for a development board that will give me an expansion > port to plug it into my project. I want something less than $100 perferably > less than $50. I am currently considering the CPLD design kit from XILINX > which has XC2C256-7TQ144 CoolRunner-II CPLD and XC9572XL-10VQ44 CPLD on it > as it seems to be a good starter package. Are there other quick dirty > solutions that will allow me to easily program a device and integrate it > with my project? I do not need something that has tons of LEDS and > pushbuttons and tons of extra proto space. > > Thank You > Josiah Vivona > > Have a look at http://www.digilentinc.com They have some nice FPGA and CPLD boards. Most of the boards contain only the necessary with nearly every IO of the FPGA or CPLD going to a connector. If needed you can add some of their IO-boards which contain the leds, push buttons, lcds, ... Kind regards, Yves
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