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
> > Perhaps my problem is that I need to use a synchronizer to bring the > "offload_flag" signal and the "rs_offload_flag" signal between clock > domains? > No, this is not the problem. Although a synchronizer is indeed useful for these signals, it is not the cause of the failing timing analysis. >> >> When you have new data in the fast domain, toggle a single bit. Read >> (register) that single bit in the slow domain. If the bit has >> changed, load the data on the next cycle. You keep track of whether >> the bit has changed with a simple clock delay of that bit in the slow >> domain. > Toggling a single bit is indeed a solution. Thank you for suggesting this.Article: 144826
> > I think that I understand how to do this. The state of the single bit > (say data[0] in a 108-bit data word) is examined for a change in the > slow clock domain. If the bit changes, then it is time to read the > data. The 108-bit register is simply copied into another register that > is in the slow clock domain. > Whoops, I think that I mean 109-bit data word here, since [108:1] would be the data, and data[0] would be the flag bit. Any other combination of data and flag bits also be possible. My apologies. Alternately, data[108] could be the flag bit, and [107:0] would then be the data. The possibilities are endless, but it is probably best to assign the MSB or the LSB as the flag bit - for the sake of simplicity.Article: 144827
MX25U : 1.8V 4-I/O Operating at speeds up to 104MHz of each I/O in 4- I/O mode, 8Mb-64Mb This device makes FPGA SoftCPU code problems a little bit easier. Two of these devices could deliver over 100MBytes of code streaming speed, or allow a Time-sliced 'dual' core to access two independant code sets. .Article: 144828
This really belongs on comp.lang.verilog, but the topic
has been flogged to death there; and Verilog users on
comp.arch.fpga may find it vaguely relevant.
On Wed, 06 Jan 2010 21:04:28 -0600, Nicholas Kinar wrote:
>> What I don't understand is the assignment logic at the top of this
>> always block. Isn't "old_slow_flag" equal to "resync_slow_flag"?
No, it's not. I carefully and correctly used a nonblocking
assignment <=, causing a delayed update of the target.
Whatever else you do, please get a robust understanding
of the relationship between blocking = and nonblocking <=
assignment before you do anything further with Verilog.
>To help me better understand this, I've re-written the code:
>
>reg old_slow_flag;
>reg slow_flag;
>
>always @(posedge fast_clock) begin
>
> if (old_slow_flag != slow_flag) begin
>
> old_slow_flag <= slow_flag;
> freeze_register <= source_data;
>
> // Do whatever it takes to indicate that
> // source_data has been consumed, and make
> // the next source_data available no more
> // than 2 fast clocks later
>
> end
> end
OK, I see what you're saying, but I'm afraid it's
completely wrong. I'm not quite sure how to respond
to this, but as a first try I'll explain why your
code is broken and then show you a slightly different
(and perhaps clearer) way to organize the design I
first offered.
Error #1: Your model will never start running in
simulation, because both regs initialize to 1'bX
(as do all regs in Verilog) and the comparison
(old_slow_flag != slow_flag)
evaluates to "unknown", because both sides of the
equality are unknown. When if() tests an unknown
condition, it (by definition) takes the "else"
branch; your code has no "else", so the if()
statement will do nothing. Consequently the regs
will remain stuck at X in simulation. By contrast,
synthesis can't handle X values and will give you
the logic you expect; but that's probably wrong
too, because....
Error #2: slow_flag is generated in the source
clock domain, and therefore may not have enough
setup and hold time relative to the target clock.
Consequently you could get an input hazard:
the comparator result (old != new), which is used
to enable various flipflops, might be detected
"true" by some of the flops and "false" by others.
That's why I took care to resynchronize it.
Subsequently you said that the fast clock is known
to be exactly 4x the slow clock; indeed, with a PLL,
you can get the slow clock's edges exactly lined up
with the fast clock's and you don't need to worry
about clock domain crossing at all. That somewhat
changes the goalposts, but my original solution
remains valid even when the two clocks are completely
asynchronous.
OK< so now let's go back to my example and see
(a) why it's right and (b) how I could recode it
to be a little easier to follow.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THIS IS THE BIT THAT YOU REALLY MUST UNDERSTAND.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
always @(posedge fast_clock) begin // line 1
resync_slow_flag <= slow_flag; // line 2
old_slow_flag <= resync_slow_flag; // line 3
if (old_slow_flag != resync_slow_flag) begin // 4
freeze_register <= source_data;
// Do other related things
end
end
On line 1, the always block waits for the next clock
edge. So far, so good.
On line 2, we copy the asynchronous signal "slow_flag"
into its resynchronizing register. However, we use <=
nonblocking assignment, which means that the updating of
resync_slow_flag is postponed until all other activity
caused by the clock edge has finished. This postponed
signal update behaviour nicely models the clock-to-output
delay of real flip-flops. In particular, it means that...
On line 3, we copy resync_slow_flag to old_slow_flag.
But the value of resync_slow_flag that we copy HAS NOT YET
BEEN UPDATED by the nonblocking assignment. In other
words, we get the flipflop's value as it was just before
the clock edge. Similarly, on line 4 the values tested
by the if() expression are the values as they were just
before the clock edge. The same would be true if those
values were tested in any other always block triggered by
the same clock event; the value that you read is the value
as it was just before (and also at the moment of) the clock
edge. New values assigned using <= are projected future
values; they will take effect just after the clock edge
and, in particular, AFTER the execution of any always
block that was triggered by the same clock. This is
precisely how you get proper synchronous behaviour in
Verilog RTL code.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
However, some folk (particularly those coming from a
software background, where assignments always update
their targets immediately) find this sort of thing a little
awkward to read. So you can, if you wish, re-code the
always block in a more software-like style provided you
give it some local variables.
always @(posedge fast_clock) begin : my_resync // 1
reg resync_slow_flag, old_slow_flag; // 2
if (old_slow_flag != resync_slow_flag) begin // 3
freeze_register <= source_data; // 4
// Do other related things // 5
end // 6
old_slow_flag = resync_slow_flag; // 7
resync_slow_flag = slow_flag; // 8
end
By labelling the "begin" on line 1, we are entitled to
declare local variables in the block (line 2). Note that
these variables are STATIC; they are NOT re-initialized
each time the block executes, but instead they hold their
value from its previous execution.
On line 3 we test those variables' values; of course, the
values we get are the values left over from the previous
clock - that's flipflop behaviour.
On lines 7 and 8 we update the variables using blocking
assignment, which takes effect immediately. Consequently
we must respect your original concerns, and reverse the
order of the two assignments so that the updating of
old_slow_flag uses the old, rather than the updated, value
of resync_slow_flag.
This use of local variables has a number of benefits. We
have hidden the variables resync_* and old_* inside the
begin...end block where they're used, and they are not
(easily) accessible by other code that shouldn't be
concerned with them. We go back to a software-like model
of execution in which local variables update instantly.
However, we MUST continue to use nonblocking assignment
to freeze_reg because it will be read by other blocks
of code, outside this particular always block. Whenever
you write to a variable within a clocked process, and that
variable will be read by any other process, it's essential
to use nonblocking assignment in this way or else you will
get catastrophic race conditions in simulation, and mismatch
between simulation and synthesis behaviour.
Asks with trepidation..... where did you learn your Verilog,
without finding out about the correct usage of <= ???
--
Jonathan Bromley
Article: 144829
On Wed, 06 Jan 2010 15:30:34 -0600, Nicholas Kinar wrote:
>> Create a divide-by-2 signal in the target domain. No
>> reset is required, because the phase of the divide-by-2
>> is irrelevant; only its changes are of interest. So
>> we use a Verilog model that doesn't need a reset in
>> simulation either:
>>
>> always @(posedge slow_clock)
>> if (slow_flag == 1'b1)
>> slow_flag <= 0;
>> else
>> slow_flag <= 1;
>>
>
>I see - all that is being done here is a simple clock divisor. Perhaps
>this could also be done with a shift register?
I'm not quite sure what you mean here. In principle, the simplest
possible clock divisor is
always @(posedge clock)
clock_2 <= ~clock_2;
It is indeed a shift register; on each clock it shifts
the inverse of itself into itself, and it has only 1 stage.
But this doesn't work in simulation because reg clock_2 will
initialize to 1'bx, and ~(1'bx) is 1'bx so the divisor will be
stuck at X. It would work in synthesis.
My model works around the stuck-at-X problem without requiring
any explicit reset in simulation. There are several other ways
to get the same effect, but the one I offered is probably the
least hassle and the most portable across tools. It will
synthesise to just one flipflop and one inverter; I don't see
how you can do any better.
--
Jonathan Bromley
Article: 144830Hello JF, I recommend that you take a look at http://www.parsec.co.za/pm432.php Best Regards, --jmvArticle: 144831
>On Jan 6, 12:19=A0am, grigio <crowne...@gmail.com> wrote: >> On 2 Gen, 19:21, Weng Tianxiang <wtx...@gmail.com> wrote: >> >> > Hi, >> > I need to write ASM hardware language for circuits. I wrote a lot >> > about 10 years ago for Altera chip. Now I couldn't find the ASM >> > hardware language definition file from Altera/Xilinx. >> >> Perhaps PALASM? > >Yes, it is similar language, but Altera has its own language name, and >not called PALASM. > >Weng > Do you mean AHDL? --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144832
Hello there,
I'm adding custom IP (DCT core) to EDK 9.1. Input (xin) is write to
slv_reg0 while output (dct2d_out) is write to slv_reg1.
I'm following a tutorial from
http://www.ee.cooper.edu/~stefan/projects/tutorials/edk_custom_ip/edk_custom_ip.pdf
I can write and read from the slv_reg0 (for input, xin), but I cannot
read the value from slv_reg1 (for dct2d_out). The output enable,
rdy_out is used to enable writing dct2d_out value to the slv_reg1.
Can anyone point me out any correction should i make.
Thanks in advance.
=============================================
user_logic.vhd
------------------------------------------------------------------------------
-- user_logic.vhd - entity/architecture pair
------------------------------------------------------------------------------
-- DO NOT EDIT BELOW THIS LINE --------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library proc_common_v2_00_a;
use proc_common_v2_00_a.proc_common_pkg.all;
-- DO NOT EDIT ABOVE THIS LINE --------------------
--USER libraries added here
------------------------------------------------------------------------------
-- Entity section
------------------------------------------------------------------------------
entity user_logic is
generic
(
-- ADD USER GENERICS BELOW THIS LINE ---------------
--USER generics added here
-- ADD USER GENERICS ABOVE THIS LINE ---------------
-- DO NOT EDIT BELOW THIS LINE ---------------------
-- Bus protocol parameters, do not add to or delete
C_DWIDTH : integer := 32;
C_NUM_CE : integer := 2
-- DO NOT EDIT ABOVE THIS LINE ---------------------
);
port
(
-- ADD USER PORTS BELOW THIS LINE ------------------
--USER ports added here
-- ADD USER PORTS ABOVE THIS LINE ------------------
-- DO NOT EDIT BELOW THIS LINE ---------------------
-- Bus protocol ports, do not add to or delete
Bus2IP_Clk : in std_logic;
Bus2IP_Reset : in std_logic;
Bus2IP_Data : in std_logic_vector(0 to
C_DWIDTH-1);
Bus2IP_BE : in std_logic_vector(0 to
C_DWIDTH/8-1);
Bus2IP_RdCE : in std_logic_vector(0 to
C_NUM_CE-1);
Bus2IP_WrCE : in std_logic_vector(0 to
C_NUM_CE-1);
IP2Bus_Data : out std_logic_vector(0 to
C_DWIDTH-1);
IP2Bus_Ack : out std_logic;
IP2Bus_Retry : out std_logic;
IP2Bus_Error : out std_logic;
IP2Bus_ToutSup : out std_logic
-- DO NOT EDIT ABOVE THIS LINE ---------------------
);
end entity user_logic;
------------------------------------------------------------------------------
-- Architecture section
------------------------------------------------------------------------------
architecture IMP of user_logic is
--USER signal declarations added here, as needed for user logic
component dct
PORT (
CLK : IN std_logic;
RST : IN std_logic;
xin : IN std_logic_vector(7 downto 0); --
8 bit input.
dct_2d : OUT std_logic_vector(11 downto 0);
rdy_out : OUT std_logic);
END component;
------------------------------------------
-- Signals for user logic slave model s/w accessible register
example
------------------------------------------
signal slv_reg0 : std_logic_vector(0 to
C_DWIDTH-1);
signal slv_reg1 : std_logic_vector(0 to
C_DWIDTH-1);
signal slv_reg_write_select : std_logic_vector(0 to 1);
signal slv_reg_read_select : std_logic_vector(0 to 1);
signal slv_ip2bus_data : std_logic_vector(0 to
C_DWIDTH-1);
signal slv_read_ack : std_logic;
signal slv_write_ack : std_logic;
signal dct_2d_i : std_logic_vector(0 to 11);
signal rdy_out_i : std_logic;
begin
--USER logic implementation added here
dct_0 : dct
port map (
CLK => Bus2IP_Clk,
RST => Bus2IP_Reset,
xin => slv_reg0(0 to 7),
dct_2d => dct_2d_i,
rdy_out => rdy_out_i
);
slv_reg_write_select <= Bus2IP_WrCE(0 to 1);
slv_reg_read_select <= Bus2IP_RdCE(0 to 1);
slv_write_ack <= Bus2IP_WrCE(0);-- or Bus2IP_WrCE(1);
slv_read_ack <= Bus2IP_RdCE(0) or Bus2IP_RdCE(1);
-- implement slave model register(s)
SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is
begin
if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
if Bus2IP_Reset = '1' then
slv_reg0 <= (others => '0');
-- slv_reg1 <= (others => '0');
else
case slv_reg_write_select is
when "10" =>
for byte_index in 0 to (C_DWIDTH/8)-1 loop
if ( Bus2IP_BE(byte_index) = '1' ) then
slv_reg0(byte_index*8 to byte_index*8+7) <= Bus2IP_Data
(byte_index*8 to byte_index*8+7);
end if;
end loop;
-- when "01" =>
-- for byte_index in 0 to (C_DWIDTH/8)-1 loop
-- if ( Bus2IP_BE(byte_index) = '1' ) then
-- slv_reg1(byte_index*8 to byte_index*8+7) <=
Bus2IP_Data(byte_index*8 to byte_index*8+7);
-- end if;
-- end loop;
when others => null;
end case;
end if;
end if;
end process SLAVE_REG_WRITE_PROC;
write_enable_process : process (Bus2IP_Clk) is
begin
if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
if Bus2IP_Reset = '1' then
slv_reg1 <= (others => '0');
else
case rdy_out_i is
when '0' => slv_reg1 <= (others => '0');
when '1' => slv_reg1 <= dct_2d_i;
when others => slv_reg1 <= (others => '0');
end case;
end if;
end if;
end process write_enable_process;
-- slv_reg1(13 to 15) <= (others => '0');
-- implement slave model register read mux
SLAVE_REG_READ_PROC : process( slv_reg_read_select, slv_reg0,
slv_reg1 ) is
begin
case slv_reg_read_select is
when "10" => slv_ip2bus_data <= slv_reg0;
when "01" => slv_ip2bus_data <= slv_reg1;
when others => slv_ip2bus_data <= (others => '0');
end case;
end process SLAVE_REG_READ_PROC;
------------------------------------------
-- Example code to drive IP to Bus signals
------------------------------------------
IP2Bus_Data <= slv_ip2bus_data;
IP2Bus_Ack <= slv_write_ack or slv_read_ack;
IP2Bus_Error <= '0';
IP2Bus_Retry <= '0';
IP2Bus_ToutSup <= '0';
end IMP;
========================================================
========================================================
my software application code.
#include "xparameters.h"
#include "stdio.h"
#include "my_dct.h"
#include "xbasic_types.h"
Xuint32 *baseaddr_p = (Xuint32 *)XPAR_MY_DCT_0_BASEADDR;
int main()
{
Xuint32 baseaddr, i;
// Check that the peripheral exists
XASSERT_NONVOID(baseaddr_p != XNULL);
baseaddr = (Xuint32) baseaddr_p;
Xuint16 data[8], data_read;
data[0]=0x28;
data[1]=0x21;
data[2]=0x21;
data[3]=0x16;
data[4]=0x1A;
data[5]=0x28;
data[6]=0x24;
data[7]=0x1A;
for(i=0; i<8; i++)
{
MY_DCT_mWriteSlaveReg0(baseaddr, data[i]);
data_read = MY_DCT_mReadSlaveReg0(baseaddr);
xil_printf("data write to reg0: 0x%04X\r\n", data_read);
}
for(i=0; i<8; i++)
{
data_read = MY_DCT_mReadSlaveReg1(baseaddr);
xil_printf("data read from reg1: 0x%04X\r\n", data_read);
}
return 0;
}
=============================================================================
============================================================================
this is the ouput from terminal.
data write to reg0: 0x0028
data write to reg0: 0x0021
data write to reg0: 0x0021
data write to reg0: 0x0016
data write to reg0: 0x001A
data write to reg0: 0x0028
data write to reg0: 0x0024
data write to reg0: 0x001A
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
data read from reg1: 0x0000
======================================================================
Article: 144833Hi, I must admit that I'm searching for the VHDL-code that combines the PCI core and the algorithm. >On Jan 5, 8:06=A0am, "Ghostboy" <Ghost...@dommel.be> wrote: >> Hi, >> >> I first want to use the I/O space because I think the most simple >> implementation. >> The possibility to use DMA is not in this core. >> If I make a zip file can you open it then? It might be easier to see the >> problem. >> >> I'm streaming an entire file by the way. >> >What work have you done or *can* you do? You've used system generator >and other high level tools. Are you familiar with low level FPGA >design? Are you looking to get someone to do this low level design >work for you? > >Is your need on the PC driver for the XUPV2P such that you need >software help? > >Having a zip file I can actually look at won't help me to help you if >I don't know what you need. > >I've suggested on the FPGA side that you use the writes to the FPGA >(quantity and/or addresses) to know when a fram of data is available >and that you use a PCI interrupt to tell the PC when the FPGA is >done. You specifically asked for those. > >What more are you asking for? > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144834
Hi Folks I have recently become very interested in FPGA and DSP. Could somebody suggest to me a newbee started book and also a related experimental board. I would also like to know the differences between the different Virtex families like Virtex 2, 4, 5 etc. Regards RKArticle: 144835
>On Jan 6, 2:18=A0pm, "mlajevar" <mahsa_lajeva...@yahoo.com> wrote: >> >> I got that the values on LEDs is the half of the value I expect from the >> formula,so I think the problem would be with the 14th bit in my vhdl >> code,because from 13th bit to LSB ,all bits are almost same,but the big >> difference comes from being half of the original value caused by 14th >> bit. > >Keep in mind that on a serial interface being off by a factor of two >in your read value is the same as having the value off by one clock in >the serial domain. Perhaps you're actually missing the least >significant bit! > From experience, this is an all-too-common problem with SPI and other serial interfaces... --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144836
Hello Jonathan-- Thank you once again for your detailed response. This is very much appreciated. > This really belongs on comp.lang.verilog, but the topic > has been flogged to death there; and Verilog users on > comp.arch.fpga may find it vaguely relevant. > Sure, but I find that comp.arch.fpga tends to be slightly more active than comp.lang.verilog. So when I weighed the possibilities of posting there, I thought that I would go with comp.arch.fpga because clock domain crossing is a topic that encompasses all work with FPGAs. > > Error #1: Your model will never start running in > simulation, because both regs initialize to 1'bX > (as do all regs in Verilog) and the comparison > (old_slow_flag != slow_flag) > evaluates to "unknown", because both sides of the > equality are unknown. When if() tests an unknown > condition, it (by definition) takes the "else" > branch; your code has no "else", so the if() > statement will do nothing. Consequently the regs > will remain stuck at X in simulation. By contrast, > synthesis can't handle X values and will give you > the logic you expect; but that's probably wrong > too, because.... I try to initialize registers so that everything is in a known state. reg old_slow_flag = 0; reg slow_flag = 0; But your example code takes into consideration the 1'bX condition and is more robust. > > Error #2: slow_flag is generated in the source > clock domain, and therefore may not have enough > setup and hold time relative to the target clock. > Consequently you could get an input hazard: > the comparator result (old != new), which is used > to enable various flipflops, might be detected > "true" by some of the flops and "false" by others. > That's why I took care to resynchronize it. > Okay, now I understand the reasons for resynchronization. > > OK< so now let's go back to my example and see > (a) why it's right and (b) how I could recode it > to be a little easier to follow. Thank you for going over this line-by-line. > always @(posedge fast_clock) begin // line 1 > resync_slow_flag <= slow_flag; // line 2 > old_slow_flag <= resync_slow_flag; // line 3 > if (old_slow_flag != resync_slow_flag) begin // 4 > freeze_register <= source_data; > // Do other related things > end > end > > On line 2, we copy the asynchronous signal "slow_flag" > into its resynchronizing register. However, we use <= > nonblocking assignment, which means that the updating of > resync_slow_flag is postponed until all other activity > caused by the clock edge has finished. This postponed > signal update behaviour nicely models the clock-to-output > delay of real flip-flops. In particular, it means that... This nicely explains what is happening with the non-blocking assignment. > On line 3, we copy resync_slow_flag to old_slow_flag. > But the value of resync_slow_flag that we copy HAS NOT YET > BEEN UPDATED by the nonblocking assignment. Ah! - okay. This explains the behavior of the code. In other > words, we get the flipflop's value as it was just before > the clock edge. Similarly, on line 4 the values tested > by the if() expression are the values as they were just > before the clock edge. The same would be true if those > values were tested in any other always block triggered by > the same clock event; the value that you read is the value > as it was just before (and also at the moment of) the clock > edge. New values assigned using <= are projected future > values; they will take effect just after the clock edge > and, in particular, AFTER the execution of any always > block that was triggered by the same clock. This is > precisely how you get proper synchronous behaviour in > Verilog RTL code. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > However, some folk (particularly those coming from a > software background, where assignments always update > their targets immediately) find this sort of thing a little > awkward to read. That would be me! So you can, if you wish, re-code the > always block in a more software-like style provided you > give it some local variables. > > always @(posedge fast_clock) begin : my_resync // 1 > reg resync_slow_flag, old_slow_flag; // 2 > if (old_slow_flag != resync_slow_flag) begin // 3 > freeze_register <= source_data; // 4 > // Do other related things // 5 > end // 6 > old_slow_flag = resync_slow_flag; // 7 > resync_slow_flag = slow_flag; // 8 > end > This is a nice example. > By labelling the "begin" on line 1, we are entitled to > declare local variables in the block (line 2). Note that > these variables are STATIC; they are NOT re-initialized > each time the block executes, but instead they hold their > value from its previous execution. > On line 3 we test those variables' values; of course, the > values we get are the values left over from the previous > clock - that's flipflop behaviour. > On lines 7 and 8 we update the variables using blocking > assignment, which takes effect immediately. Consequently > we must respect your original concerns, and reverse the > order of the two assignments so that the updating of > old_slow_flag uses the old, rather than the updated, value > of resync_slow_flag. > > This use of local variables has a number of benefits. We > have hidden the variables resync_* and old_* inside the > begin...end block where they're used, and they are not > (easily) accessible by other code that shouldn't be > concerned with them. We go back to a software-like model > of execution in which local variables update instantly. > However, we MUST continue to use nonblocking assignment > to freeze_reg because it will be read by other blocks > of code, outside this particular always block. Whenever > you write to a variable within a clocked process, and that > variable will be read by any other process, it's essential > to use nonblocking assignment in this way or else you will > get catastrophic race conditions in simulation, and mismatch > between simulation and synthesis behaviour. > > Asks with trepidation..... where did you learn your Verilog, > without finding out about the correct usage of <= ??? I am actually an environmental physicist who has had to self-teach myself Verilog and everything to do with FPGAs. It is impossible to really grasp the nuances of the language, the technology and the ideas without participating in some sort of community, despite the proliferation of "crash-courses" and "learn HDL in a week" materials. Such courses and books may get you started, but there is always a lack of experience. That's the reason why I rely on your help and the help of other people on this newsgroup.Article: 144837
>>> >>> always @(posedge slow_clock) >>> if (slow_flag == 1'b1) >>> slow_flag <= 0; >>> else >>> slow_flag <= 1; >>> >> I see - all that is being done here is a simple clock divisor. Perhaps >> this could also be done with a shift register? > > I'm not quite sure what you mean here. In principle, the simplest > possible clock divisor is > > always @(posedge clock) > clock_2 <= ~clock_2; > > It is indeed a shift register; on each clock it shifts > the inverse of itself into itself, and it has only 1 stage. > > But this doesn't work in simulation because reg clock_2 will > initialize to 1'bx, and ~(1'bx) is 1'bx so the divisor will be > stuck at X. It would work in synthesis. I'm fond of setting the register to zero when it is initialized reg clock_2 = 0; But I believe that some older versions of the Verilog language standard do not support this, and your code always ensures that this will work. > > My model works around the stuck-at-X problem without requiring > any explicit reset in simulation. There are several other ways > to get the same effect, but the one I offered is probably the > least hassle and the most portable across tools. It will > synthesise to just one flipflop and one inverter; I don't see > how you can do any better. > Yes I agree - it's a very clean solution.Article: 144838
rk <ajrajkumar@gmail.com> wrote: > Hi Folks > I have recently become very interested in FPGA and DSP. Could somebody > suggest to me a newbee started book and also a related experimental board. > I would also like to know the differences between the different Virtex > families like Virtex 2, 4, 5 etc. Where did you start? Where did you struggle? Try www.xilinx.com... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 144839
On Jan 7, 2:41=A0am, "RCIngham" <robert.ing...@gmail.com> wrote: > >On Jan 6, 12:19=3DA0am, grigio <crowne...@gmail.com> wrote: > >> On 2 Gen, 19:21, Weng Tianxiang <wtx...@gmail.com> wrote: > > >> > Hi, > >> > I need to write ASM hardware language for circuits. I wrote a lot > >> > about 10 years ago for Altera chip. Now I couldn't find the ASM > >> > hardware language definition file from Altera/Xilinx. > > >> Perhaps PALASM? > > >Yes, it is similar language, but Altera has its own language name, and > >not called PALASM. > > >Weng > > Do you mean AHDL? > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com Hi, Thank you. It is AHDL. Where can I find its definition file now? WengArticle: 144840
>On Jan 7, 2:41=A0am, "RCIngham" <robert.ing...@gmail.com> wrote: >> >On Jan 6, 12:19=3DA0am, grigio <crowne...@gmail.com> wrote: >> >> On 2 Gen, 19:21, Weng Tianxiang <wtx...@gmail.com> wrote: >> >> >> > Hi, >> >> > I need to write ASM hardware language for circuits. I wrote a lot >> >> > about 10 years ago for Altera chip. Now I couldn't find the ASM >> >> > hardware language definition file from Altera/Xilinx. >> >> >> Perhaps PALASM? >> >> >Yes, it is similar language, but Altera has its own language name, and >> >not called PALASM. >> >> >Weng >> >> Do you mean AHDL? >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> This message was sent using the comp.arch.fpga web interface onhttp://www= >.FPGARelated.com > >Hi, >Thank you. It is AHDL. Where can I find its definition file now? > >Weng > I suggest that you start at: http://quartushelp.altera.com/current/mergedProjects/hdl/ahdl/ahdl_intro.htm If you have QuartusII on your local PC, the same information should be in its help files. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144841
Hi All, I'm speccing out a new windows PC that I'll use with Xilinx tools, probably Webpack and Modelsim, and I'm looking for some advice to make sure the tools will run fast. I know memory is important, but what else? Also, what pitfalls should I watch out for? I'm not sure how relevant this info is, but I'm probably going to target something in the ballpark of a Virtex-5 LX50. Also, I'm planning on getting a laptop because I'll need to travel quite a bit with it. Some specific questions: - Have people had any problems with Windows 7? 32 bit or 64? Is it useful to have Win 7 Pro so that I can use XP mode? - Core 2 Duo vs i7? - How important is cache size? - How much memory should I get? Is 4GB enough? Thanks! -TomArticle: 144842
hi, Tom Kotwal wrote: > - Core 2 Duo vs i7? depends if you can find a laptop with it. It seems to be quite worth it but the i7 is much more expensive... It may have changed since the last time I've looked, Intel has just announced i7 derivatives (i5 and i3 from memory, look /.) for desktops and laptops. > - How important is cache size? very. So choose the laptop with the largest L2 & L3, over raw speed : being memory access dependent, many P&R algos will stall the CPU... Also those algos are difficult to parallelize so don't waste money on a quad-core, one core will be busy with P&R while the other will remain for the OS GUI. Oh, I think that some Toshiba have 2 (two !) disk drive slots. Might be interesting in RAID :-) > - How much memory should I get? Is 4GB enough? should be, add some swap too. Check that your OS supports as much (well, the recent kernels support at least 64GB but MS's marketing department has crippled actual /use/ of detected RAM, see a past /. article). But FAST memory and several channels are recommended. Bandwidth and access time are to be preferred. With small designs on Actel, I have seen that I don't consume as much memory as I thought. Like 500M peak or so... Vista consumes about as much :-D Now I have not succeeded in running it under Linux but I expect much more comfort. ... I'm currently going the other route with a /small/ ACER ONE netbook (Atom dual-thread CPU, XP and single DDR2 slot upgraded to 2GB) so I can S&P&R in travel. I wonder what the results will be, compared to the somewhat bulkier Toshiba with a Core2 at the same CPU speed. Price and size have been halved, however :-) But given that most of the time is lost clicking the same dialogs all the time, and that those damn antiviruses/toolbars/indexers/GUI widgets waste RAM&cycles, I don't expect a big difference... The much smaller size and the lower price make it more like a commodity, something replaceable and that can be carried along... > Thanks! happy hacking, > -Tom yg -- http://ygdes.com / http://yasep.orgArticle: 144843
rk wrote: > Hi Folks > > I have recently become very interested in FPGA and DSP. Could somebody > suggest to me a newbee started book and also a related experimental board. > > I would also like to know the differences between the different Virtex > families like Virtex 2, 4, 5 etc. > > Regards > RK > > Perhaps the kits from Digilent would be of interest? http://www.digilentinc.com/ There is also an inexpensive learning board available from Avnet: http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm A plethora of other vendors offer learning kits. One such vendor can be found here: http://www.knjn.com/ If you are searching for a repository of HDL code, OpenCores works well: http://www.opencores.org/Article: 144844
On Jan 7, 7:31=A0am, "Ghostboy" <Ghost...@dommel.be> wrote: > Hi, > > I must admit that I'm searching for the VHDL-code that combines the PCI > core and the algorithm. There is no VHDL code ready-made and drop-in to connect the PCI core to your algorithm. The PCI core has its own interface with associated timing and enables while the algorithm has its own interface with timing and enables. You also need to manage the data coming from the PC to process and make the data available to the PC once processes, flagging the system with a PCI interrupt. Do you have someone you can leverage where you are? Perhaps treat them to dinner or a beverage to help you get this stuff together? It's several hours of work for someone who knows reasonably well what they're doing and are familiar with the PCI core basics. For a beginner it might be a few days before things get moving. You're not in a real good position to just "make it happen" without knowing what to do "under the hood." Good luck with this.Article: 144845
>rk <ajrajkumar@gmail.com> wrote: >> Hi Folks > >> I have recently become very interested in FPGA and DSP. Could somebody >> suggest to me a newbee started book and also a related experimental board. > >> I would also like to know the differences between the different Virtex >> families like Virtex 2, 4, 5 etc. > >Where did you start? Where did you struggle? > >Try www.xilinx.com... > >-- >Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > >Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt >--------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Hi Yes, I have been to that website, and I see a lot of datasheets for Virtex-2, 4, 5, 6 etc, but I do not able to get a comprehensive evolution of the family and the enhancements in sucessive 2, 4, 5 etc families. Also, I am looking for a good book along with a board that I can but and develop some hands on experience. Visiting www.xilinx.com results in an information overload for a beginner. Regards RK --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144846
On Thu, 07 Jan 2010 09:24:27 -0800, Tom Kotwal wrote: > Hi All, > > I'm speccing out a new windows PC that I'll use with Xilinx tools, > probably Webpack and Modelsim, and I'm looking for some advice to make > sure the tools will run fast. I know memory is important, but what else? > Also, what pitfalls should I watch out for? > > I'm not sure how relevant this info is, but I'm probably going to target > something in the ballpark of a Virtex-5 LX50. Also, I'm planning on > getting a laptop because I'll need to travel quite a bit with it. > > Some specific questions: > > - Have people had any problems with Windows 7? 32 bit or 64? Is it > useful to have Win 7 Pro so that I can use XP mode? - Core 2 Duo vs i7? > - How important is cache size? > - How much memory should I get? Is 4GB enough? > > Thanks! > > -Tom For simulation cache size is very important. My benchmarking on Linux shows that NC simulations run about 10% faster clock for clock on a Core2 with a 6M two level cache vs an iCore7 with a three level cache. The difference between a 6M Core2 and a 4M Core2 is even greater. For Xilinx place and routes the iCore7 is a little faster clock for clock. One reason to get an iCore7 is that it can hold 12G of RAM at reasonable prices. The large members of the V5 family need more than 8G, the LX300 uses 10G for example. If you are only using smaller FPGAs then 8G is fine. I wouldn't consider anything less than 8G these days. You also need a 64bit OS. If you must use Windows then get a 64 bit version.Article: 144847
On Jan 7, 3:01=A0pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > On Thu, 07 Jan 2010 09:24:27 -0800, Tom Kotwal wrote: > > Hi All, > > > I'm speccing out a new windows PC that I'll use with Xilinx tools, > > probably Webpack and Modelsim, and I'm looking for some advice to make > > sure the tools will run fast. I know memory is important, but what else= ? > > Also, what pitfalls should I watch out for? > > > I'm not sure how relevant this info is, but I'm probably going to targe= t > > something in the ballpark of a Virtex-5 LX50. Also, I'm planning on > > getting a laptop because I'll need to travel quite a bit with it. > > > Some specific questions: > > > - Have people had any problems with Windows 7? 32 bit or 64? Is it > > useful to have Win 7 Pro so that I can use XP mode? - Core 2 Duo vs i7? > > - How important is cache size? > > - How much memory should I get? Is 4GB enough? > > > Thanks! > > > -Tom > > For simulation cache size is very important. My benchmarking on Linux > shows that NC simulations run about 10% faster clock for clock on a Core2 > with a 6M two level cache vs an iCore7 with a three level cache. The > difference between a 6M Core2 and a 4M Core2 is even greater. For Xilinx > place and routes the iCore7 is a little faster clock for clock. > > One reason to get an iCore7 is that it can hold 12G of RAM at reasonable > prices. The large members of the V5 family need more than 8G, the LX300 > uses 10G for example. If you are only using smaller FPGAs then 8G is > fine. I wouldn't consider anything less than 8G these days. > > You also need a 64bit OS. If you must use Windows then get a 64 bit > version. I'm running LX85T and LX110T designs pretty comfortably in 32-bit Windows XP. Check with Xilinx before jumping into Windows 7, I don't think the support is quite there yet. Also WinXP has been around long enough to run the older versions you'll need to support the legacy devices. If you're not a GUI-driver, and want raw performance you're probably best off with a 64-bit Linux rather than Windows. I've seen many more bug reports on the Windows tool versions. It may just be that more people use them, but I think the general consensus is that the best performance comes using Linux. If you need the notebook for typical office applications in addition to the Xilinx stuff you may want to weigh that into your OS choice, too. Multiprocessor is nice for the ability to use the computer while you're running synthesis, P&R, etc. Also the multicore CPU's usually have faster front-side buses and larger cache, which makes the tools run faster. Most of the processes don't do enough disk access for the disk speed to be an issue. Just be sure your memory is big enough to avoid a lot of paging. 4GB will really be more like 3 GB if you're running 32-bit windows. regards, gaborArticle: 144848
On Jan 7, 1:01=A0pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > One reason to get an iCore7 is that it can hold 12G of RAM at reasonable > prices. The large members of the V5 family need more than 8G, the LX300 > uses 10G for example. If you are only using smaller FPGAs then 8G is > fine. I wouldn't consider anything less than 8G these days. > > You also need a 64bit OS. If you must use Windows then get a 64 bit > version. Interesting - what version of ISE are you basing this on? I'm using 10.1.3 to build against a V5 SX95T in only 4G on a Linux X86_64 system and not running into any memory issues. EricArticle: 144849
On Thu, 07 Jan 2010 13:33:43 -0800, emeb wrote: > On Jan 7, 1:01 pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > >> One reason to get an iCore7 is that it can hold 12G of RAM at >> reasonable prices. The large members of the V5 family need more than >> 8G, the LX300 uses 10G for example. If you are only using smaller FPGAs >> then 8G is fine. I wouldn't consider anything less than 8G these days. >> >> You also need a 64bit OS. If you must use Windows then get a 64 bit >> version. > > Interesting - what version of ISE are you basing this on? I'm using > 10.1.3 to build against a V5 SX95T in only 4G on a Linux X86_64 system > and not running into any memory issues. > > Eric The SX95 is substantially smaller then the LX330 so it's entirely possible that it will run in 4G. My memory usage number is using ISE 11.1 on Fedora 12. I seem to remember that it was even higher with 10.1. In any event it makes no sense having less than 8G these days, RAM is cheap. Most people don't use the biggest FPGAs, I have an LX330 board that I use for ASIC prototyping which is why I've run into the memory limits.
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