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
Good Morning I've implemented the following clock dll on Virtex
XCV1000BG560-4
It have in input a 10MHz clock and must produce a 40MHz clock
according to the XAPP132 schema for clkdll 4x , the behaviour and
backannotated simulation it's Ok but mapped on FPGA There's no clock
out ??
Is this Due to the fact that I put reset to ground according to
XAPP132 or you think there's some other problem ??
Thanks Antonio
-- Design unit header --
library IEEE;
use IEEE.std_logic_1164.all;
-- other libraries declarations
-- synopsys translate_off
library VIRTEX;
library IEEE;
use IEEE.vital_timing.all;
-- synopsys translate_on
entity clk_generator is
port(
clk_div_n_ext : in std_ulogic;
clk : out std_ulogic
);
end clk_generator;
architecture clk_generator of clk_generator is
---- Component declarations -----
component BUFG
-- synopsys translate_off
generic(
InstancePath : STRING := "*";
MsgOn : BOOLEAN := TRUE;
TimingChecksOn : BOOLEAN := false;
Xon : BOOLEAN := TRUE;
tipd_I : VitalDelayType01 := (0 ns,0 ns);
tpd_I_O : VitalDelayType01 := (0 ns,0 ns)
);
-- synopsys translate_on
port (
I : in std_ulogic;
O : out std_ulogic
);
end component;
component CLKDLL
-- synopsys translate_off
generic(
CLKDV_DIVIDE : REAL := 2.000000;
DUTY_CYCLE_CORRECTION : BOOLEAN := TRUE;
InstancePath : STRING := "*";
MAXPERCLKIN : TIME := 100 ns;
MsgOn : BOOLEAN := false;
TimingChecksOn : BOOLEAN := TRUE;
Xon : BOOLEAN := TRUE;
tipd_CLKFB : VitalDelayType01 := (0 ns,0 ns);
tipd_CLKIN : VitalDelayType01 := (0 ns,0 ns);
tipd_RST : VitalDelayType01 := (0 ns,0 ns);
tpd_CLKIN_LOCKED : VitalDelayType01 := (0 ns,0 ns);
tperiod_CLKIN : VitalDelayType := 0.01 ns;
tpw_CLKIN_negedge : VitalDelayType := 0.01 ns;
tpw_CLKIN_posedge : VitalDelayType := 0.01 ns;
tpw_RST_posedge : VitalDelayType := 0.01 ns
);
-- synopsys translate_on
port (
CLKFB : in std_ulogic := '0';
CLKIN : in std_ulogic := '0';
RST : in std_ulogic := '0';
CLK0 : out std_ulogic := '0';
CLK180 : out std_ulogic := '0';
CLK270 : out std_ulogic := '0';
CLK2X : out std_ulogic := '0';
CLK90 : out std_ulogic := '0';
CLKDV : out std_ulogic := '0';
LOCKED : out std_ulogic := '0'
);
end component;
component IBUFG
-- synopsys translate_off
generic(
InstancePath : STRING := "*";
MsgOn : BOOLEAN := TRUE;
TimingChecksOn : BOOLEAN := false;
Xon : BOOLEAN := TRUE;
tipd_I : VitalDelayType01 := (0 ns,0 ns);
tpd_I_O : VitalDelayType01 := (0 ns,0 ns)
);
-- synopsys translate_on
port (
I : in std_ulogic;
O : out std_ulogic
);
end component;
component INV
-- synopsys translate_off
generic(
InstancePath : STRING := "*";
MsgOn : BOOLEAN := TRUE;
TimingChecksOn : BOOLEAN := false;
Xon : BOOLEAN := TRUE;
tipd_I : VitalDelayType01 := (0 ns,0 ns);
tpd_I_O : VitalDelayType01 := (0 ns,0 ns)
);
-- synopsys translate_on
port (
I : in std_ulogic;
O : out std_ulogic
);
end component;
component SRL16
-- synopsys translate_off
generic(
INIT : BIT_VECTOR := X"0000";
InstancePath : STRING := "*";
MsgOn : BOOLEAN := TRUE;
TimingChecksOn : BOOLEAN := false;
Xon : BOOLEAN := TRUE;
thold_D_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
thold_D_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
tipd_A0 : VitalDelayType01 := (0 ns,0 ns);
tipd_A1 : VitalDelayType01 := (0 ns,0 ns);
tipd_A2 : VitalDelayType01 := (0 ns,0 ns);
tipd_A3 : VitalDelayType01 := (0 ns,0 ns);
tipd_CLK : VitalDelayType01 := (0 ns,0 ns);
tipd_D : VitalDelayType01 := (0 ns,0 ns);
tpd_A0_Q : VitalDelayType01 := (0 ns,0 ns);
tpd_A1_Q : VitalDelayType01 := (0 ns,0 ns);
tpd_A2_Q : VitalDelayType01 := (0 ns,0 ns);
tpd_A3_Q : VitalDelayType01 := (0 ns,0 ns);
tpd_CLK_Q : VitalDelayType01 := (0 ns,0 ns);
tpw_CLK_negedge : VitalDelayType := 0.01 ns;
tpw_CLK_posedge : VitalDelayType := 0.01 ns;
tsetup_D_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
tsetup_D_CLK_posedge_posedge : VitalDelayType := 0.01 ns
);
-- synopsys translate_on
port (
A0 : in std_ulogic;
A1 : in std_ulogic;
A2 : in std_ulogic;
A3 : in std_ulogic;
CLK : in std_ulogic;
D : in std_ulogic;
Q : out std_ulogic
);
end component;
---- Constants -----
constant VCC_CONSTANT : STD_LOGIC := '1';
constant GND_CONSTANT : STD_LOGIC := '0';
---- Signal declarations used on the diagram ----
signal GND : STD_LOGIC;
signal NET101 : std_ulogic;
signal NET63 : std_ulogic;
signal NET65 : std_ulogic;
signal NET69 : std_ulogic;
signal NET83 : std_ulogic;
signal NET92 : std_ulogic;
signal NET99 : std_ulogic;
signal to_out_clk : std_ulogic;
signal VCC : STD_LOGIC;
---- Configuration specifications for declared components
-- synopsys translate_off
for U1 : CLKDLL use entity virtex.CLKDLL;
-- synopsys translate_on
-- synopsys translate_off
for U2 : CLKDLL use entity virtex.CLKDLL;
-- synopsys translate_on
-- synopsys translate_off
for U3 : IBUFG use entity virtex.IBUFG;
-- synopsys translate_on
-- synopsys translate_off
for U5 : BUFG use entity virtex.BUFG;
-- synopsys translate_on
-- synopsys translate_off
for U6 : BUFG use entity virtex.BUFG;
-- synopsys translate_on
-- synopsys translate_off
for U7 : INV use entity virtex.INV;
-- synopsys translate_on
-- synopsys translate_off
for U9 : SRL16 use entity virtex.SRL16;
-- synopsys translate_on
begin
---- Component instantiations ----
U1 : CLKDLL
port map(
CLK2X => NET63,
CLKFB => NET83,
CLKIN => NET92,
LOCKED => NET65,
RST => GND
);
U2 : CLKDLL
port map(
CLK2X => NET99,
CLKFB => to_out_clk,
CLKIN => NET83,
RST => NET101
);
U3 : IBUFG
port map(
I => clk_div_n_ext,
O => NET92
);
U5 : BUFG
port map(
I => NET63,
O => NET83
);
U6 : BUFG
port map(
I => NET99,
O => to_out_clk
);
U7 : INV
port map(
I => NET69,
O => NET101
);
U9 : SRL16
port map(
A0 => VCC,
A1 => VCC,
A2 => VCC,
A3 => VCC,
CLK => NET83,
D => NET65,
Q => NET69
);
---- Power , ground assignment ----
VCC <= VCC_CONSTANT;
GND <= GND_CONSTANT;
---- Terminal assignment ----
-- Output\buffer terminals
clk <= to_out_clk;
end clk_generator;
Article: 39326
One technique for a uniform distribution is to run the LFSR at a faster
rate and use groups of bits to generate your density. For example, for a
1 in 8 density you could use 3 consecutive bits out of an LFSR, if they
are all '0' then the output is '1', otherwise it is zero. You have to
advance the LFSR by 3 bits per output sample in order to make this work.
You can't just take multiple bits out of the LFSR on each clock because
the additional bits are just time shifted copies of the first bit.
ALternatively you could use parallel LFSRs each seeded at a different
place in the sequence so that you can get a new output on every clock. If
you used, say 16 uniquely seeded long LFSRs, you could get an arbitrary
threshold on a uniform variable that could be set at anywhere from 0 to
65535/65536. If you do this in xilinx, the individual LFSRs can be made
very compact (1 CLB) using the SRL16 shift registers (and they could
easily be long enough not to repeat within your lifetime once seeded).
Another technique, which allows you to get at arbitrary distributions, is
to use the LFSR value as a key to search a cdf table. (you could address
the table directly if it is small enough). This technique is discussed
briefly in my paper, "An FPGA Based Processor Yields a Real Time High
Fidelity Radar Environment Simulator" which is available on my website.
In that case a binary search engine used a 32 bit LFSR as a key to a 32
bit wide by 128 word deep table containing the CDF of the distribution (in
that case it was a modified Rayleigh distribution).
Achim Gratz wrote:
> [I posted a similar message earlier, but it seems it didn't get
> through. My apologies if you see this twice.]
>
> Hello,
>
> I would like to know if there are efficient methods, easily
> implementable with high speed in an FPGA, to produce a pseudorandom
> bitstream with a known and finely, at runtime adjustable density of 1s
> or 0s. The density would be below 1/8 or 1/32, this excludes densities
> around 0.5 that are easily obtained with LSFR. If several such
> bitstreams could be produced that have no correlation amongst each
> other that would be great. The randomness really is only a requirement
> as far as the correlation/autocorrelation properties go and that the
> bandlimited spectrum of the integral of the signal must be white.
>
> I have found a few leads on LFSR implementations that yield pink
> instead of white noise, but AFAIK noone figured out how to obtain
> arbitrary let alone continuously adjustable frequency responses. Plus
> the pink noise, to the best of my knowledge, is not obtained from the
> bitstream, but some code the LFSR outputs.
>
> Any hints in which directions I might search?
>
> Achim.
--
--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: 39327If I understand you, you are running a post P&R simulation using the build in simulator from Altera, right? The way you can speed up your development is to do less gate level (post P&R) simulation. If your design is synchronous, and coded correctly, you need to do little to no post P&R simulation but should be relying more on the static timing analysis (setup/hold checks). Run your sims at RTL for the bulk of your system level functionality (packet parsing, whatever). If you don't trust your synthesizer, then that should be addressed seperately rather than with repeated gate level sims. Regards, Jay "Paul" <nospam@nospamplease.com> wrote in message news:<o1Z78.4838$il3.839543@news6-win.server.ntlworld.com>... > I'm investigating ways of improving my development throughput. > > At the moment I'm using Leonardo Altera Edition for synthesis, Altera > Quartus 2 for P&R and Quartus 2's simulator. > Targeting Apex 20KE600-1X devices > > I'm using an Athlon 1GHz with 512MB RAM. > > I'm in the middle of a project and am finding that as the design comes > together, compilation and more especially simulation is becoming a real > problem. > > I realise that the most positive step may be to either use the Modelsim > Altera edition or invest in a full Modelsim license. > > The problem is that Modelsim does appear somewhat more cryptic than using > Alteras offering. Plus I'm mid-project so changing from my *.vwf approach to > modelsim may take time I haven't got. :) > > What I'd like is > > a) How much better is Modelsim than Altera's own simulator especially for > post layout analysis. Since that's like asking about string length, I'd > accept anecdotal evidence based on your own designs :Ž) > > b) Are full versions of Modelsim that much faster than the Altera edition. > > c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual > processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound > or memory bandwidth bound) and does an MP setup provide any noticeable > improvement or are all tools resolutely single threaded. > > d) Any other suggestions. > > I am already trying as best I can to restructure testing to minimise the > issues, but these 10 hour simulation times (when it doesn't crash) are > really non-productive. > > Paul > > Background on the design, though probably of limited additional help: > > Typically my designs use a lot of EABs as FIFOs, a lot of 32bit register > moving about and various high speed memory interfaces 120MHz SDRAM x 2 on > each chip. Logic is relatively simple and I believe I've taken enough > pipelining precautions to limit routing problems. > > I'm trying to simulate passing message packets in, processing them, storing > them, acting upon them etc. To capture a large part of this as the system > comes together I'm finding I need simulations of up to 10ms (though 1ms is > more typical). > > I've simulated at individual block level, so its really only the last level > of testing thatArticle: 39328
Hi all, éven if I do not understand the very aggressive postings of some of you (what is wrong with ls_users opinion?) I would like to mention that - not only Lattice sells GALīs (also Cypress and Atmnel do so) - there are larger GALīs available than 22V10īs (just think of the 26CV12) I canīt find anything bad with it. Those devices have been uses for several years and the reason is very clear: The GAL/PAL is a good and easily understandable piece of silicon. No matter if you like it or not.Article: 39329
Thanks Jay That was exactly my rational when I started the project, unfortunately two things got in the way: 1) Altera's functional simulation appears the same speed as its timing analysis (at least in Q2 1.1 SP2). Perhaps I'm doing something wrong? 2) I did some tests on a 32 bit counter fed by cout of a 24bit (mod 10,000,000 counter), The Fmax was 84MHz but a timing simulation showed it didn't work correctly when rolling over from FFFFFFFF to 00000000 with a system clock of 80MHz. I looked at the static timing analysis but couldn't see why. Note my vwf file only consisted of the clock signal, so not alot could be wrong with my stimuli waveform. I suspect that because the cout of the 24bit counter is also used elsewhere, the fast carry chains weren't modelled correctly. Disconnecting the other output from the cout pin, it was as per fmax calculation. Anyway it shook my faith a little more (and lets face Quartus is as reliable as a custard castle). Hence my desire to do more timing simulation albeit mainly of the 120MHz and 80MHz datapaths. I should point out that this particular piece of code is just an example. Simulating long counter toggling sequences is often counter-productive with very long run times. I appreciate the good advice though. At present I'm investigating Modelsim AE and am probably going to evaluate Aldec ActiveHDL as an alternative. Paul Baxter "Jay" <kayrock66@yahoo.com> wrote in message news:d049f91b.0202061101.5aa1e3d0@posting.google.com... > If I understand you, you are running a post P&R simulation using the > build in simulator from Altera, right? The way you can speed up your > development is to do less gate level (post P&R) simulation. If your > design is synchronous, and coded correctly, you need to do little to > no post P&R simulation but should be relying more on the static timing > analysis (setup/hold checks). Run your sims at RTL for the bulk of > your system level functionality (packet parsing, whatever). If you > don't trust your synthesizer, then that should be addressed seperately > rather than with repeated gate level sims. > > Regards, > Jay > > > "Paul" <nospam@nospamplease.com> wrote in message news:<o1Z78.4838$il3.839543@news6-win.server.ntlworld.com>... > > I'm investigating ways of improving my development throughput. > > > > At the moment I'm using Leonardo Altera Edition for synthesis, Altera > > Quartus 2 for P&R and Quartus 2's simulator. > > Targeting Apex 20KE600-1X devices > > > > I'm using an Athlon 1GHz with 512MB RAM. > > > > I'm in the middle of a project and am finding that as the design comes > > together, compilation and more especially simulation is becoming a real > > problem. > > > > I realise that the most positive step may be to either use the Modelsim > > Altera edition or invest in a full Modelsim license. > > > > The problem is that Modelsim does appear somewhat more cryptic than using > > Alteras offering. Plus I'm mid-project so changing from my *.vwf approach to > > modelsim may take time I haven't got. :) > > > > What I'd like is > > > > a) How much better is Modelsim than Altera's own simulator especially for > > post layout analysis. Since that's like asking about string length, I'd > > accept anecdotal evidence based on your own designs :Ž) > > > > b) Are full versions of Modelsim that much faster than the Altera edition. > > > > c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual > > processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound > > or memory bandwidth bound) and does an MP setup provide any noticeable > > improvement or are all tools resolutely single threaded. > > > > d) Any other suggestions. > > > > I am already trying as best I can to restructure testing to minimise the > > issues, but these 10 hour simulation times (when it doesn't crash) are > > really non-productive. > > > > Paul > > > > Background on the design, though probably of limited additional help: > > > > Typically my designs use a lot of EABs as FIFOs, a lot of 32bit register > > moving about and various high speed memory interfaces 120MHz SDRAM x 2 on > > each chip. Logic is relatively simple and I believe I've taken enough > > pipelining precautions to limit routing problems. > > > > I'm trying to simulate passing message packets in, processing them, storing > > them, acting upon them etc. To capture a large part of this as the system > > comes together I'm finding I need simulations of up to 10ms (though 1ms is > > more typical). > > > > I've simulated at individual block level, so its really only the last level > > of testing thatArticle: 39330
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0202061049.3612bf54@posting.google.com... > Good Morning I've implemented the following clock dll on Virtex > XCV1000BG560-4 > It have in input a 10MHz clock and must produce a 40MHz clock > according to the XAPP132 schema for clkdll 4x , the behaviour and > backannotated simulation it's Ok but mapped on FPGA There's no clock > out ?? > Is this Due to the fact that I put reset to ground according to > XAPP132 or you think there's some other problem ?? "Wer lesen kann ist klar im Vorteil" The english version of this phrase is more compact. RTFM!!! The minimum input frequency for a DLL is 25 MHz, if you are lucky you get a part with BIG reserves which go down to 15MHz, once I had one that worked down to 13 MHz. But 10 is NONO. -- MfG FalkArticle: 39331
I wasn't sure if you mean't the behavioural or sythesizable. For the later, do web search on Linear Feedback Shift Registers (LFSR). Regards piiszo <sdkfjh@oiwergy.ksdjf> wrote in message news:<ee74832.1@WebX.sUN8CHnE>... > but ,i want to get source code.Article: 39332
whazzup wrote: > Hi all, > > éven if I do not understand the very aggressive postings of some of you (what is wrong with ls_users opinion?) I would like to mention that > > - not only Lattice sells GALīs (also Cypress and Atmnel do so) > - there are larger GALīs available than 22V10īs (just think of the 26CV12) > > I canīt find anything bad with it. Those devices have been uses for several years and the reason is very clear: The GAL/PAL is a good and easily understandable piece of silicon. No matter if you like it or not. How about 36 macrocells for $1.75 in 25-off.? XC9636XL-5-VQ44 on the Xilinx web site, and you can order them through your credit card, and the s/w's free, and they are in-system reprogrammable (download cable's about $70). If you want very low power (IIRC the 26CV12 got very hot at high speeds) go for the CoolRunner XCR3032 @ $3.20 each. I sometime thing these little devices are more "magic class" even than big complex FPGAs.Article: 39333
Hi, Nevertheless, what I wrote in my messages - was after a lot of such experiments at lower level modules and with the possibilities (sure, not all 100%, but...) of Leo2001, level 3 So what can I do is - all preliminary works by Leo, resulting synthesis - by Synopsys. Thanks to all for replies. Igor Peker P.S. I sent this link to info@exemplar.com and asked their comments. It was at Febr 1. Yet silence.Article: 39334
Hi, What libbaries should I reference to make preliminary timing simulation by ModelSim just after optimization and generating SDF file by Leonardo - not after Altera P&R? What are extension of them and where to search - either in ModelSim or Leo folders? Thanks in advance, Igor PekerArticle: 39335
Niv, Can you put it back with FPGA Editor? I know that is a pain, but maybe it un-sticks you? Austin niv wrote: > Well, sussed out my problem with my DPRAM built with BlockRAMs. > > It's all Xilinx fault. They've owned up to "accidentally" removing the pin > polarity option for signals on Coregen BlockRAMs that goes with 3.3. > > I had built a DPRAM with clka using a -ve clock edge in coregen with 3.1i > However, this isn't supported in 3.3, so the PAR tool just didn't connect my > clock to the BlockRAM. Wonderful! (NOT). > > Apparently, pin polarity is back in 4.1, I'll have to wait for our IT > support group to install it, but god knows when that'll be; they're useless > most of the time when it comes to putting on new s/w. We're usually a t > least one release behind what's available in both Xilinx and Mentor tools. > > Enough whinging, time for some more VHDL; at least the text editor doesn't > need upgrading! > > Regards, NivArticle: 39336
Mike, One can design the circuits and the process so the inputs can't latch up. It is related to the beta (or alpha) of the parasitic npn and pnp transistors that are connected in an SCR arangement. It turns out that there are process tricks, implants, etc. that are done to minimize the gain so that the scr can't stay ON. Too bad the SDRAM folks had to get to market so fast.... Of course, it helps to have been there and done that. Austin Mike Treseler wrote: > rk wrote: > > the claim was that groundbounce in the FPGA > > from SSO's caused the SDRAM to latchup; this was supposed to explain a > > functional failure that would be cleared by cycling the power. > > Any CMOS device can latch up if device pins > are forced below ground with enough energy. > > CMOS wells and substrates combine to form > unintended n-p-n-p (SCR) structures. > > If these get triggered you get a > a pretty good short from power to > ground through the device. > > This may destroy the chip, or if you are lucky, > requires a power cycle to turn off the SCR. > > To fix this, you need a better ground plane > and/or better supply bypassing. > > > For a low, quiet output, they measured a 710 > > mV peak below ground; that doesn't sound too bad, > > That is above the maximum low value for most devices, > another indication an inadequate ground plane. > > -- Mike TreselerArticle: 39337
When I use the fnd to synthesis the design and ModelSim to simulation, I'll first compile the fnd's Simprims and uniprims to the own library in modelsim, and while loading the design in modelsim, it need specify the library at dialog, or use the 'uselib at source file. I think the Leo is the same as.Article: 39338
Read below... > That was exactly my rational when I started the project, unfortunately two > things got in the way: > > 1) Altera's functional simulation appears the same speed as its timing > analysis (at least in Q2 1.1 SP2). Perhaps I'm doing something wrong? You may be right, I haven't used the built in simulator for years because I usually go with the HDL test bench style these days. I don't think people really use the built in simulator for anything except the really small designs. > 2) I did some tests on a 32 bit counter fed by cout of a 24bit (mod > 10,000,000 counter), The Fmax was 84MHz but a timing simulation showed it > didn't work correctly when rolling over from FFFFFFFF to 00000000 with a > system clock of 80MHz. I looked at the static timing analysis but couldn't > see why. > Note my vwf file only consisted of the clock signal, so not alot could be > wrong with my stimuli waveform. This may be a silly question but did you by any chance feed the carry out of the first counter directly into the clock pin of the second counter? If you did, then this would not be standard synchronous design as such, and the static timing check would not be meaningful. > I suspect that because the cout of the 24bit counter is also used elsewhere, > the fast carry chains weren't modelled correctly. Disconnecting the other > output from the cout pin, it was as per fmax calculation. If you're following the rules, and the timing sim deviates from the static timing prediction, then kick Altera in the butt and send them a zip file with the example. It's no guarantee they'll ever fix it, but at least you proved the tool sucks and produced a test case. > Anyway it shook my faith a little more (and lets face Quartus is as reliable > as a custard castle). That was my unfortunate experience also. >Hence my desire to do more timing simulation albeit > mainly of the 120MHz and 80MHz datapaths. Oh man, if you can't trust the tools, quit now. Hey, you know you could always get that Xilinx Web Pack thingy.... Just kidding! =) BTW, I use the ModelSim XE sometimes for small stuff I know it can do when I don't want to move my dongle to another machine. > I should point out that this particular piece of code is just an example. > Simulating long counter toggling sequences is often counter-productive with > very long run times. > > I appreciate the good advice though. You're welcome. > > At present I'm investigating Modelsim AE and am probably going to evaluate > Aldec ActiveHDL as an alternative. Modelsim seems to be the defacto standard from what I've seen. I'm sure they're both very capable tools. If you can make the design small enough, you can use the free tools (ModelSim XE).Article: 39339
Is your approach too simplistic? No way man, its right on. Look at CATC's USB serial bus analyzer, thats what he did. For a onesy twosy kind of application you might even be able to get a data acquisition card or use a logic analyzer with a link to a PC (TCP/IP or HP-IB) as your front end and do the parsing in VB or whatever. My motto is "make the hardware soft, and make the software hard". Regards strut911@hotmail.com (strut911) wrote in message news:<4379d3e0.0202061033.1fb0aadd@posting.google.com>... > hello. > i have been given the task of designing a protocol analyzer for my > company's proprietary serial bus to help speed up the software design. > i guess that means it needs to be finished quickly because software is > really struggling right now. i have never designed a protocol analyzer > before, but my first instincts are that i will need an fpga, a bunch > or RAM (or Block RAM) if the quantity is sufficient, and a > microcontroller. the serial bus runs at a max speed of 25 mhz although > it can be slower if needed. i think it would be no problem to hit that > target in today's FPGAs. my main question would be how to partition > the hardware and software to be optimal to the design. my first > thoughts were to take the incoming serial data, dump it all to memory > when some trigger condition is asserted, and then have software > post-process it into the various protocol control or data fields. if > it is this easy (i doubt it is), then my fpga requirements would be > minimal. however, when i look at the ethernet protocol analyzer my > company has, it looks quite a bit more sophisticated than my > minimalist design. > another idea i had was to forget the microcontroller, and dump the > memory contents to a PC when the data acquisition is finished. that > way, i can let the PC post-process all the data and put it in a nice, > colorful gui. are my ideas too simplistic? > strut911Article: 39340
If you are new at using HDL's to design ciruits, it is very possible you have coded something that will not behave the same in gates (post synthesis) as it does in RTL form. Often time the sythesizer will warn you of these coding style issues, but not always. You should run a post syth, pre P&R simulation against you existing test-bench and see if it flys. If it doesn't you, among other techniques, you can replace on by one, each module with its RTL version until you make it work. Good luck to you! shengyu_shen@hotmail.com (ssy) wrote in message news:<f4a5f64f.0201310054.234aa10f@posting.google.com>... > Hi every one > > I am using sopc board from altera, it hold an APEX20k400E, I am using > synplicity 6.2.4 to synthesis and then use quartus II 1.1 to P&R, > > my design is an cpu, the cpu hold one cpu core(design by me), an > interconnect network(design by other), and some slave device(design by > my team member) > > the cpu core have two master port to fetch instruction and data > > the interconnect network have 8 master and 16 slave, any unuse port's > output pin will not connect and input pin will assign 0, > > I run pre syn rtl simulation, all ok,but after burn on the board, it > is error, > > I want to know possible cause of synthesis/simulation mismatch.Article: 39341
Symphony EDA is pleased to announce a new version of VHDL Simili.
VHDL Simili is a VHDL compiler, simulator which can be used standalone
(command-line) or in the supplied advanced integrated development
environment.
This release adds many *new* capabilities:
** Advanced Integrated Development Environemnt
** Full-featured project management
Auto file ordering, manage multiple libraries, smart
compile, and much more.
** Windows 98/ME/NT/2000/XP
** Linux Redhat 7.1+
** High performance, high capacity waveform viewer
Can handle millions of transitions with ease
** Support for VHDL configurations with generic/port maps
** License management using FLEXlm (node-locked or floating)
** Hassle free license fulfillment over the internet
These new capabilities enhance the already capable compiler and
simulator that you are familiar with from the previous version:
** Very fast compiler and simulator
** VHDL 93, Vital/SDF support
** Contains support scripts and docs for many vendors
Altera, Xilinx, Synopsys etc.
** Designed for professional use
Symphony EDA would like to invite you to try out the graphical
version -- simply download, install and use the Licensing Wizard
to retrieve trail licenses (requires an Ethernet card on your PC).
If you have already tried VHDL Simili 2.0 and would like to purchase
a license, the secure online store is now open.
Please visit the following links for more details
http://www.symphonyeda.com (has a couple of screen shots)
http://www.symphonyeda.com/products.htm
Many regards,
Haneef Mohammed
Symphony EDA
PS: Please remove the .nospam from the email address if you wish
to reply directly to me. For a general question please reply
to the newsgroup instead.
Article: 39342On Wed, 06 Feb 2002 01:14:29 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Jay wrote: > >> Why don't you give it a rough cut, then synth, and P&R and see what >> you get. If you're a designer of similar caliber to some of the >> regular posters on here then you should have a good shot at it. We >> run our ECC SDRAM interface at 25MHz, but then again, its a standard >> cell design being proto'd in a Vertex 2 6000, not a purpose build FPGA >> design. >> > >So far I've manged to push ours to 100MHz or so in an XCV600E-6, no floorplanning or hard >macro'ing, just the auto P&R tools. The target/goal, after some floorplanning & much >sweat+cursing etc, is 125/133Mhz in a -7. > >Then, sometime in April, we'll move to the V2 and I'll start similing again. I recently did one at 133MHz in an XCV2000E-7. No problems at all, and no floorplanning required. It was heavily pipelined though, as latency doesn't matter for my particular application. Regards, Allan.Article: 39343
I have been working with Altera MAX7000 PLD's in my new project and i have encountered some problems which i cannot solve. I was wondering if anyone knew of specific newsgroups for this series of chip. Alternatively i was wondering if someone know how to solve these problems. Error: Node for pin "BusClock" must have the same name as the pin Error: Node for pin "BusFrame" must have the same name as the pin I have checked the names and they match, i was wondering why this was occuring??Article: 39344
Rick Lyons wrote:
>
>
> >I just wish there was some bonded credential I could get that stated
> >"Bob Cain is not a student nor is he assisting one." :-)
> >Bob
>
> Ah ha! That credential would be handy for a student
> to have! Are you sure you're not a student Bob? ;-)
> [Maybe a student of the 'School of Hard Knocks'.]
I'll be a student in that school probably forever. :-)
>
> Yea, it happens. I once posted a question about
> solving equations containing complex exponentials
> whose real parts are non-zero. [e^(a +jb)]
> Someone teased me that my question looked like
> a homework problem, and that surprised/shocked
> me. No matter though, 'cause then the fellow
> proceeded to help me out for which I really was
> grateful. The guy's answer forced me to stick my
> toes in the chilly waters of hyperbolic functions.
> Brrrrr!
Yeah, that's what I mean. Even at my "advanced age" I still stumble
across things like functional analysis and wavelets and Kolmogorov
complexity where I know I've got yet another plunge that must be taken.
Now what's this about hyperbolic functions? :-)
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
http://www.intel.com/cure
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Article: 39345
Hi Haneef,
Few days back I downloaded Simli's new version on my new XP
based system, command line works fine as ever before. Yet to try out
your new GUI. Meanwhile I tried to run LEON processor example on
Simli, it compiles fine, but during simulation (VHDLE), it says
"Unknown Fatal Error, contact Symphony EDA" (or something similar
message). I couldn't figure out what's going wrong. Would you like to
try it out? The example data is available at:
http://www.estec.esa.nl/wsmwww/leon/
I also tried in 1.5 version with the same result.
Thanks and Regards,
Srinivasan
--
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"
"Haneef Mohammed" <haneefd@attbi.com.nospam> wrote in message
news:7Nm88.3428$AV5.53979@rwcrnsc51.ops.asp.att.net...
> Symphony EDA is pleased to announce a new version of VHDL Simili.
> VHDL Simili is a VHDL compiler, simulator which can be used
standalone
> (command-line) or in the supplied advanced integrated development
> environment.
> <SNIP>
Article: 39346Allan Herriman wrote: > On Wed, 06 Feb 2002 01:14:29 +0000, Rick Filipkiewicz > <rick@algor.co.uk> wrote: > > > > > > >Jay wrote: > > > >> Why don't you give it a rough cut, then synth, and P&R and see what > >> you get. If you're a designer of similar caliber to some of the > >> regular posters on here then you should have a good shot at it. We > >> run our ECC SDRAM interface at 25MHz, but then again, its a standard > >> cell design being proto'd in a Vertex 2 6000, not a purpose build FPGA > >> design. > >> > > > >So far I've manged to push ours to 100MHz or so in an XCV600E-6, no floorplanning or hard > >macro'ing, just the auto P&R tools. The target/goal, after some floorplanning & much > >sweat+cursing etc, is 125/133Mhz in a -7. > > > >Then, sometime in April, we'll move to the V2 and I'll start similing again. > > I recently did one at 133MHz in an XCV2000E-7. No problems at all, > and no floorplanning required. It was heavily pipelined though, as > latency doesn't matter for my particular application. > > Regards, > Allan. Yes. That's the difficulty I face - CPU read latency is critical in my app so I can't go the "natural" FPGA way with lots of pipeline stages. What I'll probably do is add some stages as "scaffolding" to check that no board SI issues get in the way of 133MHz, get Linux running reliably, then figure out how to remove them.Article: 39347
Hi Haneef, You might want to grep over html source for your web page and remove all the "file:///C:/My%20Webs/" as they aren't very portable :) Regards, Allan.Article: 39348
Oh, I know of this but I was thinking that this apply only for divider capabilities of clkdll not also multiply. this means I've to go out from the FPGA with at least 100MHz, but this seems to be to much for the DINI board I use. By the way, to what is due this limitation of CLKDLL ?? AntonioArticle: 39349
Hi All,
Trying to set up a simple design flow at home using FREE EDA
tools, I tried using Webpack for synthesis, but after synthesis I
couldn't see any schematics. I know that Webpack can write EDIF (but
not quite sure how to do that - if someone knows please do let me
know) or Verilog netlist as output, but is there any schematic viewer
(free) for the same? After some web search I found one at
http://www.e-tools.com/content/download.html (EStudiopro), but when I
try to run the same, it says "License expired" - though the web page
doesn't talk about any license for this particular product.
Any links is greatly appreciated.
TIA,
Srinivasan
--
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"
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