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
Utku Ozcan wrote: > Design entry: Verilog > Synthesis: Synplify v6.24 > P&R: Xilinx M3.1i SP8 IP4 > OS: Sun Solaris 2.6 > Technology: Xilinx XC9572XL-5TQ100C > > Xilinx tools reverse vectors in netlists generated by themselves. > > I have vectors like: > > output [1:2] add_ck_a; > output [1:4] dck; > input [4:5] drp_mux_c; > > I synthesize my code in Synplify and run Design Manager and > Design Manager generates Verilog netlist in which the vectors > above are reversed: > > input [5:4] drp_mux_c; > output [2:1] add_ck_a; > output [4:1] dck; > > I know this can be compensated by instantiation. > But is it possible to keep the vector direction during implementation? > > Utku Utku, If Design Manager is calling NGD2VER to produce the netlist then this is a known ``feature''. Have a look at the ``Bus order in Verilog files'' subsection of the NGD2VER chapter of the Development System Reference Guide. It means that either: o All top level ports have to be written ``littleendian'', or, o The bit order in the testbench instantiation has to be reversed between HDL & post route simulations. irritating!Article: 37951
On Thu, 27 Dec 2001 11:12:33 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Utku Ozcan wrote: > >> Design entry: Verilog >> Synthesis: Synplify v6.24 >> P&R: Xilinx M3.1i SP8 IP4 >> OS: Sun Solaris 2.6 >> Technology: Xilinx XC9572XL-5TQ100C >> >> Xilinx tools reverse vectors in netlists generated by themselves. >> >> I have vectors like: >> >> output [1:2] add_ck_a; >> output [1:4] dck; >> input [4:5] drp_mux_c; >> >> I synthesize my code in Synplify and run Design Manager and >> Design Manager generates Verilog netlist in which the vectors >> above are reversed: >> >> input [5:4] drp_mux_c; >> output [2:1] add_ck_a; >> output [4:1] dck; >> >> I know this can be compensated by instantiation. >> But is it possible to keep the vector direction during implementation? >> >> Utku > >Utku, > >If Design Manager is calling NGD2VER to produce the netlist then this is a >known ``feature''. Have a look at the ``Bus order in Verilog files'' >subsection of the NGD2VER chapter of the Development System Reference >Guide. > >It means that either: > >o All top level ports have to be written ``littleendian'', or, > >o The bit order in the testbench instantiation has to be reversed between >HDL & post route simulations. > >irritating! The same applies to NGD2VHDL. One gets into the habit of always defining top level ports as "downto". The NGD2xxx programs don't have the information about the original "direction" so they pick one. Most of the time it's ok... Another gotcha is that the post route code won't have any of the ports that were "optimised" away. E.g. if your RTL has a port such as input [31:0] address; and your design ignores the least significant bit, the post route code will have a port input [31:1] address; which may cause problems in your test bench. Regards, Allan.Article: 37952
> [snip] > > Utku, > > If Design Manager is calling NGD2VER to produce the netlist then this is a > known ``feature''. Have a look at the ``Bus order in Verilog files'' > subsection of the NGD2VER chapter of the Development System Reference > Guide. > > It means that either: > > o All top level ports have to be written ``littleendian'', or, > > o The bit order in the testbench instantiation has to be reversed between > HDL & post route simulations. > > irritating! Rick, thank your very much that you have pointed me the document. I have never used big-endian bus order before, so it is good to know the ``feature'' from now on. Yes, irritating! Have a nice Xmas and Happy New Year! UtkuArticle: 37953
<dgeerinck@yahoo.com> wrote: >I saw this year some basics of vhdl at school. >I'm now looking for some kind of FPGA-starterkit who allows me >to experiment on simple I/O like leds, LCD screens, com-ports, >... Digilent also sells FPGA kits: http://www.digilentinc.com/Products/digilab_xla.html http://www.digilentinc.com/Products/digilab_2.html http://www.digilentinc.com/Products/digital_i_o.html RW.Article: 37954
Hello VHDL Users,
It was one of my long pending wishes to provide the VHDL
community (atleast a part of them who use NC tools) to provide a
"feature" to be able to "probe" internals signals of your DUT in
Testbenches in a cleaner fashion (than using Global Signals etc.). As
you may all know Modelsim has this so called "Signal Spy" available
for quite some time. Thanks to Martyn Pollard of Cadence I got a small
piece of C-code for a similar functionality with Cadence's NC-VHDL
tool and I have just made a quick sample run and made minor
improvements (nothing major yet) and have uploaded to
http://www.vlsisrini.com/ Please feel free to download it and suggest
(or bombard ?) any improvements that you would like to see.
Have a Great New Year!
Kind Regards,
Srinivasan
P.S. The direct link to the actual page is:
http://in.geocities.com/srinivasan_v2001/technical/nc_signal_spy.htm)
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
"I don't Speak for Intel"
Article: 37955
Hi.
I'm doing my first steps with VHDL and I face a problem with
concurrent
statements.
My design targets the Atmel FPSLIC, and I actually run it on the
silicon for testing. It implements a variable rotate (for RC5
encryption). 32 bits of data are given to the FPGA into "val_in"
together with a shift count ("shift"). Concurrent statements
evaluate val_out = val_in >>> shift, so that "val_out" can be
read back later by the microcontroller portion of the FPSLIC.
This works fine when the last line of the source (below) is
val_out <= val_in;
or
val_out <= val0; -- rotated by 0 or 1 bit positions
so that the input value is used directly or rotated only once.
As soon as I use the other rotation-taps val1..3 or the final tap
val4, the result is garbled. There are one or several bits wrong,
usually "0"-bits turn into "1"-bits. The majority of bits is
correct however.
The idea behind my design is that the result is evaluated in
several stages. Each stage operates on the result of the
previous stage. Maybe this is the problem. I think in terms
of hardware and expect the states of the higher stages to
settle later than the first stages. Much like the higher
bits of a ripple counter.
There is enough time available for this, the microcontroller
pauses 1 ms before reading back val_out. Reading back several
times does not change anything either. There is no race
condition.
Here is the VHDL source, please help:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_bit.all;
ENTITY rotate IS
PORT (
SEL : in std_logic;
RD : in std_logic;
WR : in std_logic;
XTAL : in std_logic;
DIN : in std_logic_vector (7 downto 0);
DOUT : out std_logic_vector (7 downto 0)
);
END rotate;
ARCHITECTURE rotate_b OF rotate IS
SIGNAL rd_state : integer RANGE 0 TO 3 := 0;
SIGNAL wr_state : integer RANGE 0 TO 4 := 0;
SIGNAL shift : STD_LOGIC_VECTOR ( 4 downto 0);
SIGNAL val_in : STD_LOGIC_VECTOR (31 downto 0);
SIGNAL val_out : STD_LOGIC_VECTOR (31 downto 0);
signal val0 : STD_LOGIC_VECTOR (31 downto 0);
signal val1 : STD_LOGIC_VECTOR (31 downto 0);
signal val2 : STD_LOGIC_VECTOR (31 downto 0);
signal val3 : STD_LOGIC_VECTOR (31 downto 0);
signal val4 : STD_LOGIC_VECTOR (31 downto 0);
signal rd_qual : std_logic;
signal wr_qual : std_logic;
begin --- support signals
rd_qual <= (SEL and RD); --- qualified read
wr_qual <= (SEL and WR); --- qualified write
--- state machine to control reads and writes
statemachine : PROCESS (rd_qual,wr_qual,XTAL)
variable rd_qual_int : std_logic;
variable wr_qual_int : std_logic;
begin
if (falling_edge(XTAL)) then
rd_qual_int := rd_qual;
wr_qual_int := wr_qual;
end if;
if (rising_edge(XTAL)) then
if (rd_qual_int='1') then --- advance rd_state, reset wr_state
rd_state <= rd_state +1;
wr_state <= 0;
end if;
if (wr_qual_int='1') then --- advance wr_state, reset rd_state
wr_state <= wr_state +1;
rd_state <= 0;
end if;
end if;
end process statemachine;
--- microcontroller writes 32 bit "val_in" and 5 bit "shift" value in
5 consecutive writes
input : PROCESS (wr_qual,wr_state,XTAL)
begin
if (falling_edge(XTAL)) then
if wr_qual='1' then
case wr_state is
when 0 => val_in ( 7 downto 0) <= DIN (7 downto 0);
when 1 => val_in (15 downto 8) <= DIN (7 downto 0);
when 2 => val_in (23 downto 16) <= DIN (7 downto 0);
when 3 => val_in (31 downto 24) <= DIN (7 downto 0);
when 4 => shift (4 downto 0) <= DIN (4 downto 0);
end case;
end if;
end if;
end process input;
--- microcontroller reads 32 bit "val_out" in 4 consecutive reads
output : PROCESS (rd_qual,rd_state,val_out)
begin
if rd_qual='1' then
case rd_state is
when 0 => DOUT (7 downto 0) <= val_out ( 7 downto 0);
when 1 => DOUT (7 downto 0) <= val_out (15 downto 8);
when 2 => DOUT (7 downto 0) <= val_out (23 downto 16);
when 3 => DOUT (7 downto 0) <= val_out (31 downto 24);
end case;
else
DOUT <= "ZZZZZZZZ";
end if;
end process output;
--- the rotate function
sh0 : PROCESS (XTAL,shift,val_in)
variable val0_int: STD_LOGIC_VECTOR (31 downto 0);
begin
if shift(0)='1' then
val0_int (31 downto 0) := val_in(0) & val_in(31 downto
1);
else
val0_int (31 downto 0) := val_in(31 downto 0);
end if;
val0 <= val0_int;
end process sh0;
sh1 : PROCESS (shift,val0,xtal)
variable val1_int: STD_LOGIC_VECTOR (31 downto 0);
begin
if shift(1)='1' then
val1_int (31 downto 0) := val0( 1 downto 0) & val0(31 downto 2);
else
val1_int (31 downto 0) := val0(31 downto 0);
end if;
val1 <= val1_int;
end process sh1;
sh2 : PROCESS (shift,val1)
variable val2_int: STD_LOGIC_VECTOR (31 downto 0);
begin
if shift(2)='1' then
val2_int (31 downto 0) := val1( 3 downto 0) & val1(31 downto 4);
else
val2_int (31 downto 0) := val1(31 downto 0);
end if;
val2 <= val2_int;
end process sh2;
sh3 : PROCESS (shift,val2)
variable val3_int: STD_LOGIC_VECTOR (31 downto 0);
begin
if shift(3)='1' then
val3_int (31 downto 0) := val2( 7 downto 0) & val2(31 downto 8);
else
val3_int (31 downto 0) := val2(31 downto 0);
end if;
val3 <= val3_int;
end process sh3;
sh4 : PROCESS (shift,val3)
variable val4_int: STD_LOGIC_VECTOR (31 downto 0);
begin
if shift(4)='1' then
val4_int (31 downto 0) := val3(15 downto 0) & val3(31 downto 16);
else
val4_int (31 downto 0) := val3(31 downto 0);
end if;
val4 <= val4_int;
end process sh4;
val_out <= val4;
END rotate_b;
Article: 37956Hi, The TimingAnalyzer can be used to draw timing diagrams of digital interfaces and check for timing problems in digital systems. Signals, clocks, buses, delays, constraints, and states are easily added from the gui. The diagrams can be saved as JPG or GIF images. Scripts can written in a Java like scripting language to generate test vectors, input stimulus for simulators, test benches, the timing diagram itself, or new features. Minimum, typical, and worst case analysis can be performed to check for timing problems in the design. Delays and constraints can be user defined or specified from part libraries in text files. All files are text formatted so the user can easily add, modify, or create new libraries. Changing clock frequencies, signal parameters, or library parts allows the user to quickly check functionality with slower parts or higher frequencies. Written in Java, it runs on any platform that supports the java runtime enviroment JRE1.3. It is being tested on Windows and Linux. FREE to everyone while in Beta Testing Regards, Dan Fabrizio d2fabrizio@aol.com http://members.aol.com/d2fabrizio "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in> wrote in message news:<a0bv5m$a00@news.or.intel.com>... > Hi, > Try > > 1.> http://members.aol.com/d2fabrizio/ > 2.> http://www.timingtool.com/ > > HTH, > Srinivasan > > > "Kevin Brace" > <nospamtomyaddresskevinbraceusenet@hotmail.comnospamtomyaddress> wrote > in message news:3C281960.DB85C679@hotmail.comnospamtomyaddress... > > I am wondering if there is kind of software which I can easily draw > and > > edit bus signal waveforms with a mouse and a keyboard, and print it > out > > from a printer. > > I can think of Altera MAX+PLUS II-BASELINE's waveform editor, but > does > > anyone else know something better? > > I will like to improve my productivity, and one thing that took > forever > > during a design I worked on was drawing sample waveforms of a design > I > > am working on sheets of paper with a pencil and a ruler. > > From these sample waveforms I think about how I will design state > > machines and when I should change a value of a FF. > > After the state machine design is done, I go into HDL coding. > > So, does anyone know such a tool I am talking about? > > > > > > > > Thanks, > > > > > > > > Kevin Brace (don't respond to me directly, respond within the > newsgroup)Article: 37957
"David G." <dgeerinck@yahoo.com> wrote in message news:<3c27e328$0$10318$ba620e4c@news.skynet.be>... > Hi, > I saw this year some basics of vhdl at school. > I'm now looking for some kind of FPGA-starterkit who allows me > to experiment on simple I/O like leds, LCD screens, com-ports, > RAM, ETHERNET,etc that are accesible through a simple electronic board. > > I heard of a Xilinx starterkit but found it a bit expesive > for the pour student I am :-( > > > Thanks. > > David. More links: xess.com vcc.comArticle: 37958
Comments embedded in the code:
jetmarc wrote:
> I'm doing my first steps with VHDL and I face a problem with
> concurrent
> statements.
>
> My design targets the Atmel FPSLIC, and I actually run it on the
> silicon for testing. It implements a variable rotate (for RC5
> encryption). 32 bits of data are given to the FPGA into "val_in"
> together with a shift count ("shift"). Concurrent statements
> evaluate val_out = val_in >>> shift, so that "val_out" can be
> read back later by the microcontroller portion of the FPSLIC.
> Here is the VHDL source, please help:
What synthesis tool are you using?? And are you simulating? Burn-and-crash debugging is little more than a time-waster, especially when you are new to a design tool.
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
> use ieee.numeric_bit.all;
Why not numeric_std?
> ENTITY rotate IS
>
> PORT (
> SEL : in std_logic;
>
> RD : in std_logic;
> WR : in std_logic;
> XTAL : in std_logic;
> DIN : in std_logic_vector (7 downto 0);
> DOUT : out std_logic_vector (7 downto 0)
> );
>
> END rotate;
>
> ARCHITECTURE rotate_b OF rotate IS
>
> SIGNAL rd_state : integer RANGE 0 TO 3 := 0;
> SIGNAL wr_state : integer RANGE 0 TO 4 := 0;
>
> SIGNAL shift : STD_LOGIC_VECTOR ( 4 downto 0);
> SIGNAL val_in : STD_LOGIC_VECTOR (31 downto 0);
> SIGNAL val_out : STD_LOGIC_VECTOR (31 downto 0);
>
> signal val0 : STD_LOGIC_VECTOR (31 downto 0);
> signal val1 : STD_LOGIC_VECTOR (31 downto 0);
> signal val2 : STD_LOGIC_VECTOR (31 downto 0);
> signal val3 : STD_LOGIC_VECTOR (31 downto 0);
> signal val4 : STD_LOGIC_VECTOR (31 downto 0);
>
> signal rd_qual : std_logic;
> signal wr_qual : std_logic;
>
> begin --- support signals
>
> rd_qual <= (SEL and RD); --- qualified read
> wr_qual <= (SEL and WR); --- qualified write
>
> --- state machine to control reads and writes
>
> statemachine : PROCESS (rd_qual,wr_qual,XTAL)
>
> variable rd_qual_int : std_logic;
> variable wr_qual_int : std_logic;
>
> begin
>
> if (falling_edge(XTAL)) then
>
> rd_qual_int := rd_qual;
> wr_qual_int := wr_qual;
>
> end if;
>
> if (rising_edge(XTAL)) then
>
> if (rd_qual_int='1') then --- advance rd_state, reset wr_state
> rd_state <= rd_state +1;
> wr_state <= 0;
> end if;
>
> if (wr_qual_int='1') then --- advance wr_state, reset rd_state
> wr_state <= wr_state +1;
> rd_state <= 0;
> end if;
>
> end if;
>
> end process statemachine;
Three comments here:
1) If you want your statemachine process to be combinatorial, the ONLY
things you should have on your sensitivity list are the clock and
asyncrhonous reset.
2) Your architecture does not have flops that are sensitive to both
edges of the clock, so using both falling_edge() and rising_edge() in
the same process should've resulted in some sort of compiler error.
3) If you're looking for the edge of a non-clock signal, you'll need to
write edge-detector code. You might think that rising_edge() and
falling_edge() do that, but you'd be wrong. And it's not obvious.
> sh0 : PROCESS (XTAL,shift,val_in)
> variable val0_int: STD_LOGIC_VECTOR (31 downto 0);
> begin
> if shift(0)='1' then
> val0_int (31 downto 0) := val_in(0) & val_in(31 downto
> 1);
> else
> val0_int (31 downto 0) := val_in(31 downto 0);
> end if;
>
> val0 <= val0_int;
> end process sh0;
What's happening here is that you're trying to build a shift register
out of purely combinatorial logic. You have XTAL (assuming that's your
clock) on the sensitivity list, yet you don't use it in the process.
Oversight? Again, the only thing you want in the sensitivity list for
your flops are the clock and reset. You should read your synth tool's
manual.
You might also want to spend some quality time with a VHDL simulator.
You'll find it much easier to spot errors looking at the computer
screen, rather than with a 'scope probe.
---a
Article: 37959Allan Herriman wrote: > Another gotcha is that the post route code won't have any of the ports > that were "optimised" away. > > E.g. if your RTL has a port such as > input [31:0] address; > and your design ignores the least significant bit, the post route code > will have a port > input [31:1] address; > which may cause problems in your test bench. Another, similar, gotcha is when you have a 32-bit bidirectional data bus coming into your chip, and you drive all 32 as outputs but only actually use, say, 20 as inputs. The tools helpfully optimize away the unused 12 input paths, and the simulation model the tool spits out changes those ports to outputs, so of course your test bench complains. That's why I take care of the unused inputs by ANDing (or ORing, or whatever) them all together and driving the result out an unused pin on the chip. Unused outputs are grounded inside the chip. While this is purely brute force and uses chip resources, it's obvious (perhaps adding a comment helps) and you don't have to remember any dont_touch/no_optimize/leave_me_alone pragmas that are highly tool-dependent. --aArticle: 37960
Daniel Yap wrote: > Hi, > I am looking for a schematic diagram on Lattice Filter. Anyone can provide > me some diagram on it? Coz I am doing a FPGA project on this filter and I > need to understand the algorithm. You might do well to pick up a DSP book: Oppenheim and Shafer, perhaps. --aArticle: 37961
freny wrote: > I am using xilinx fs-2.1. In simulation I need to select the signals from the > signal menu. I am unable to add the signals as no signals are shown in the ADD > SIGNALS menu. > Can anyone help me in this respect What simulator are you using? Have you initialized it by loading the design? --aArticle: 37962
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<9vtr81$hs8un$5@ID-84877.news.dfncis.de>... > "Antonio" <dottavio@ised.it> schrieb im Newsbeitrag > news:fb35ea96.0112132356.7f43b3fe@posting.google.com... > > I'm preparing a QPSK modulator, > > until now I arrange it for a VIRTEX 1000 -4 , but it seem that could > > be impossible to use it at a maximum clock speed of 165MHz especially > > Virtex-E is faster (and cheaper). > Virtex-II is even more faster. Have you looked at Altera's Mercury devices? They're an all-copper performance-optimized architecture. Altera claims ~40% performance increase over Virtex-II and 150MHz non-pipelined 16x16 multipliers. I think the largest part in this family is slightly smaller than the XCV1000, but would be worth looking at.Article: 37963
The biggest criteria is performance. What performance do you need? A soft-core processor implemented in programmable logic will be slower than a hard-core processor. There are several soft-cores available on the market, some of these are synthesizable Verilog and VHDL verions of 6502, 8051, etc. or architecture-specific soft-cores such as Altera's Nios. If you are replacing a 68000 micro in you system, a Nios will have more horsepower than you would need. Hard-Core processors in FPGAs include Altera's ARM9 implementation (@200MHz) and Triscend's ARM7 (@50MHz.) In this case, the Altera and Triscend implementations have hard-wired processor bus interfaces, guaranteeing fast external memory bus speeds & allowing the processor to power-up and operate before the FPGA is configured (this allows the processor to configure the device.) Xilinx had announced something in a hard-core processor, but I don't believe they're shipping these parts. Another important criteria is the S/W development tools and OS support (if you require an OS.) Make certain that there are compilers and debug tools available. On an ARM or MIPs, OS and tools support will not be a problem at all. The Nios includes S/W tools and a debugger and has two RTOSes and a Linux port. Hope this helps.Article: 37964
FYI, Th Xilinx FAE who blasted Altera's Mercury CDR later realized his mistake and apologized, but with a new posting, not as a response to any posting in this thread. See below: "I am sorry to have made a basic mistake, and I apologize if I have mislead anybody. The question was about Mercury, and I answered it as if it were about APEX-II." ==================================================== So for the real scoop: 1. Mercury CDR DOES NOT require a training pattern. This is a true Clock-Data recovery circuit. 2. At 1.25Gbps the clock granularity is 14 ps, not the ridiculous 300ps Peter claims. 3. As for driver power consumption, Altera's Quartus provides a simulation-based power estimator. Try it youself & see the output power consumption for 1 bit at 1.25Gbps LVDS. Note: While APEX and Mercury provide true LVDS drivers and receivers, Xilinx uses an external resistor network (in addition to the termination resistor) to generate LVDS levels and a voltage-referenced input with the LVDS -channel tied to the reference pin for receivers.Article: 37965
In article <99d0603.0112271625.5b56fdd1@posting.google.com>, Stuart Moses <mostuus@yahoo.com> wrote: >The biggest criteria is performance. What performance do you need? >A soft-core processor implemented in programmable logic will be slower >than a hard-core processor. There are several soft-cores available on >the market, some of these are synthesizable Verilog and VHDL verions >of 6502, 8051, etc. or architecture-specific soft-cores such as >Altera's Nios. If you are replacing a 68000 micro in you system, a >Nios will have more horsepower than you would need. Also, synthesizeabel cores aren't too big these days. LEON (a Sparc V8 clone) supposidly fits in a Virtex 300 at 30-40 MHz. Also, if you are going with a soft core and need more throughput, you could always go with a multithreaded core. 4 threads of execution can buy a significant jump in clock rate (and therefore throughput) at the cost of greater latency for each individual thread. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 37966
who can post it?Article: 37967
Hi Kevin, As someone else already mentioned we have a timing diagram editor called WaveFormer that sounds like what you're looking for. It also has the capability of simulating state machine equations, so you can test out your design in the early stages and use it to automatically generate Verilog or VHDL stimulus for your design. You can download it from http://www.syncad.com/syn_down.htm. best regards, Dan Notestein SynaptiCAD IncArticle: 37968
How do I generate a .edn file in Webpack ? Thanks RobArticle: 37969
How do I set block ram contents without going through the PAR process ? Can someone point me to more info ? Thanks RobArticle: 37970
it should conform IEEE802.3Article: 37971
Rick Filipkiewicz wrote: > > Andy Hall wrote: > > > Hello, > > > > <snip> > > I've been using ModelSim for a long time now. As far as I can see its now > about as bullet-proof, at least for Verilog, as an EDA tool ever gets. The > only caveat I can see from your point of view is that most of the bugs that > are turning up these days (you are right about their near-Xilinx level of > openness) seem to be in Verilog/VHDL mixed simulation or VHDL alone. Hi Rick and Newman, Thanks for the perspective. Everything I'm hearing indicates I'm making the right decision, that makes me feel a lot more comfortable. And the Model Tech sales guys haven't made me cringe either, they've been very helpful. Similar experience to when I had to buy the Synplify seat a few years ago. > > The modelsim unix version has been working fine (tutorials only as > > yet, I'm sure I'll need to recode something before attacking my main > > project). Their port of tools written for PCs to the unix platform > > feels a lot more solid and complete than Innoveda's, which uses a > > package which translates Windoze calls to unix. > > > > We have the PC version (aka the -PE) but I was told by a support guy that, > in fact, all the development work has always been done on Unix/Linux and > then ported to the PC platform. They had Linux versions running in house a > long time before they were released. That explains it! Going in the right direction apparently. :-) That said, I'll also start off with the Windoze version, and see where that goes. > Surely it wouldn't be too hard with a bit of Perl to make a VHDL netlist > from the schematic portion of your flow ? Its what we do for board level > simulation (except, of course, its Verilog). I agree, that's what we'll have to do; it was just more convenient with the Innoveda tools that we already had. Thanks again, all! Vacation calls ... AndyArticle: 37972
******************************************************************
CALL FOR PAPERS
International Performance and Dependability Symposium (IPDS) 2002
June 23 - 26, 2002, Washington DC, U.S.
http://www.dsn.org/ipds.html
******************************************************************
******************************************************************
In the year 2002, IPDS will be organized under umbrella of DSN
(Dependable Systems and Networks) Conference, which will take
place in Washington DC, U.S., June 23 - 26, 2002.
==================================================================
OBJECTIVES
With growing strategic importance of large scale networked applications
executing on high-performance computers and broadband communication
networks, the performance and dependability of computer systems and
networks have become closely related. Designers and analysts must
consider the relationships between the occurrence of errors/failures
and their impact on performance, both in computer systems themselves
and in the interconnections between the system's components.
The International Performance and Dependability Symposium aims to bring
together academic and industrial researchers in these two areas, with
emphasis on integrating theory and practice. Relating analytical
techniques to simulations, actual measurements, and experiments will
be the broad theme of IPDS. Research relating to hardware and software
issues in parallel and distributed systems and networks will be
emphasized. The topics include but are not restricted to:
Analytical/Simulation/Measurement Techniques for
Performance/Dependability applied to:
Software/Hardware Systems
Real-Time Systems
Communication Systems
Distributed Systems
Parallel and Clustered Systems
Multiprocessing Systems
Systems for Fault-tolerance
===========================================================================
INFORMATION FOR AUTHORS
Regular papers describing original research, practical experience
reports, tool descriptions/demonstrations, and panel proposals will
be refereed and considered for publication in the Proceedings of the
2002 International Conference on Dependable Systems and Networks.
Excessively long submissions, unoriginal work, or work that is
submitted to multiple venues, will be disregarded. The title page
should include the title of the paper, author name(s), affiliations,
mailing address, phone number, fax number, and e-mail address, a maximum
150-word abstract, five keywords, the submission category (see above),
an approximate word count, and a declaration that the material has been
cleared through author affiliations. For multi-authored submissions, the
contact author should be indicated.
The format of submissions for review should be single-column, Times
11-point size, double spacing and no more than:
20 pages for Regular Papers,
10 pages for Practical Experience Reports and Tool Descriptions &
Demonstrations,
2 pages for Panel proposals.
The format for final, camera-ready submissions that have been accepted
for publication should be in accordance with IEEE standard conference
format. The paper should be submitted in electronic form: PostScript
(.ps) or Portable Document Format (.pdf) to:
http://www.dsn.org/ipds.html#Authors
***************************************************************************
Selected papers submitted under the regular paper category will be
considered for publication in a special issue of the Performance
Evaluation Journal
************************************************************************
IMPORTANT DATES
Submission: January 10, 2002
Notification: March 11, 2002
************************************************************************
Program Co-Chairs
Sachin Garg
<sgarg@avaya.com>
Avaya Labs, Avaya, Inc.
233 Mount Airy Road
Basking Ridge, NJ 07920 — USA
Phone: (+1) 908 582 3912
Fax: (+1) 908 582 5809
Zbigniew Kalbarczyk
<kalbar@crhc.uiuc.edu>
Center for Reliable and High Performance Computing
University of Illinois at Urbana-Champaign
1308 W. Main Street
Urbana, IL 61801 — USA
Phone: (+1) 217 244 7110
Fax: (+1) 217 244 5686
Tools Demonstration Chair
M. Kaâniche (LAAS-CNRS, France)
kaaniche@laas.fr
Industry Liaison
L. Votta (Motorola Inc., USA)
lvotta1@email.mot.com
COMMITTEES
Steering Committee
Chair: R. Iyer (U. of Illinois, Urbana, USA)
Co-Chair: K. Trivedi (Duke University, USA)
J. Abraham (U. of Texas, Austin, USA)
A. Avizienis (UCLA, USA)
G. Balbo (U. of Torino, Italy)
R. Chillarege (Opus360 Corp., USA)
R. Geist (Clemson University, USA)
G. Haring (U. of Vienna, Austria)
R. Harper (IBM Research, USA)
J.-C. Laprie (LAAS-CNRS, France)
R. Marie (U. of Rennes, France)
E.J. McCluskey (Stanford U., USA)
W. Sanders (U. of Illinois, Urbana, USA)
M. Woodside (Carleton U., Canada)
Program Committee
P. Barford (U. of Wisconsin, Madison, USA)
S. Chau (NASA-JPL, USA)
R. Chillarege (Opus360 Corp., USA)
G. Ciardo (College of William & Mary, USA)
J. Dugan (U. of Virginia, USA)
G. Haring (U of Vienna, Austria)
R. Harper (IBM Research, USA)
B. Haverkort (RWTH Aachen, Germany)
L. John (U. of Texas, Austin, USA)
K. Kanoun (LAAS-CNRS, France)
K. Keeton (HP Laboratories, USA)
Y. Levendel (Motorola Inc., USA)
C. Lindemann (U. of Dortmund, Germany)
S. Lumetta (U. of Illinois, Urbana, USA)
H. Madeira (U. of Coimbra, Portugal)
R. Marie (U. of Rennes, France)
P. Mehra (Compaq, USA)
W. Sanders (U. of Illinois, Urbana, USA)
M. Singhal (Ohio State U., USA)
J. Smith (U. of Wisconsin, Madison, USA)
A. Tai (I.A. Tech, Inc., USA)
M. Telek (Tech. U. of Budapest, Hungary)
T. Tsai (Avaya Inc., USA)
N. Vaidya (U. of Illinois, Urbana, USA)
A. van Moorsel (HP, USA)
M. Vouk (North Carolina State U., USA)
Ex Officio: R. Iyer and K. Trivedi
Article: 37973Hello all and Happy New Year, I have 3 modules that read and write in three different RAMs, these modules can't access the same RAM in the same time so I am now worried about any conflicts. So far, I have made a big combinatorial module that is responsible for the memories arbitration but during PAR I get many timing errors (230). I am going now to use 3 bus MUX (unregistered) from CORE GENERATOR, do you think that this is better solution to my problem? Finally, do you think that I 'd rather use registered MUX instead? Best Regards, Harris LinardakisArticle: 37974
Mardin <chens_w@yahoo.com.cn> writes: >who can post it? What conditions does it have to run under? Bit serial? 8 bit parallel? 32 bit parallel? Each is faster, but much more complicated than the previous one. Ethernet runs bit serial using a 32 bit shift register and a bunch of XOR gates. Simple enough to build 20 or so years ago. "Numerical Recipes" has a pretty good description of CRC, a little theory and some practical code. When is the homework assignment due? -- glen
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