Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Fri, 06 Feb 2009 12:50:50 -0800, Poojan Wagh wrote: > Hi, all. > > Note: I mistakenly cross-posted this to comp.lang.verilog; I meant to > post it here. > > I was wondering if anyone had any recommendations for an HDL simulator. > I'm considering Mentor ModelSim, Synopsys VCS, and Cadence IUS (NC-Sim). > > If you had to chose between the 3 for FPGA work, which one would you > chose? > > It seems that there's a huge variance in the pricing I'm getting from > the respective EDA vendors and am wondering if the more expensive > simulators are worth it. > > Also, I'm mostly a Verilog programmer. Does anyone see a big downside to > getting the ModelSim Verilog-only version? > > Background information: > I'm aware of > http://groups.google.com/group/comp.lang.verilog/browse_thread/thread/ c12a37ded957f3c/ > " > which commercial HDL-Simulator for FPGA?", so I was going to go with > ModelSim. However, I'm scratching my head wondering why VCS and IUS are > so much more expensive. I'd like to know what I'm giving up before I > make the plunge. > > I've been using Icarus Verilog for simulation up to this point. I'm also > looking at Verilator. However, I've just been given some outside IP that > is compiled (for ModelSim) or encrypted (for VCS or IUS). As a result, I > will need a commercial simulator. > > In addition, the IP provides a board-functional model (BFM). My > understanding is that I need a commercial simulator to do this level of > simulation. NC is about 4X the speed of Questa and it's wave browser is also better although Questa is much improved over the older versions of Modelsim. The cheap versions of Modelsim that come with the Xilinx and Altera tool sets are severely crippled, they are much slower than Questa.Article: 138126
Hi, I am using a Xilinx Spartan 3E for this design I have a clk and a reset coming from an external source to the fpga. I cannot be sure of the setup and hold time of the reset signal with respect to the clk. I usually use the double buffer method to synchronize any external signal to the clk. I would like to use the reset to reset my internal logic (Everything is synchronously reset) but I am wondering if the external reset signal need to go through the double buffer too before being sent to the logic. If yes, then what do I use to reset my double buffer? Thanks for the help AmishArticle: 138127
In article <ytCdnSwXYvidjRHURVn_vwA@giganews.com>, "charlie78" <uni20@hotmail.it> writes: >I resolve creating two gpio devices single-channel: >one for AG30 pin and one for AH30 pin. >In this way I could discriminate the rotation sense >checking the data of the two register. > >Is there a simplier method? >How can I check the pins of a single gpio device multichannel? Roughly, you need 2 bits of information. One is direction, the second is motion/speed. Two pins is the obvious way. The output of the encoder probably isn't in that format, but you can convert it to whatever you want with a bit of logic. Of course, you can do it with only one wire if you time share that wire. Then you need something smart on the outside to encode your dumb rotary encoder to some protocol you pick. You could use another tiny FPGA/CPLD, or a tiny uP. It would need 3 pins (and pwr/gnd and maybe clock), 2 for input from the encoder and 1 output for your FPGA. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138128
"axr0284" <axr0284@yahoo.com> wrote in message
news:f84ecb18-6d3a-484f-adf8-74a66c224bbb@v19g2000yqn.googlegroups.com...
> I have a clk and a reset coming from an external source to the fpga. I
> cannot be sure of the setup and hold time of the reset signal with
> respect to the clk.
That makes the reset signal asynchronous to the clock
> I usually use the double buffer method to synchronize any external
> signal to the clk.
>
That's the ticket for synchronizing...
> I would like to use the reset to reset my internal logic (Everything
> is synchronously reset) but I am wondering if the external reset
> signal need to go through the double buffer too before being sent to
> the logic.
Yes. The reason is because of what can happen when the external reset goes
away. While reset is active of course everything gets reset but when reset
happens to go away just before or just after the clock (i.e. it when it
violates the setup or hold time of the flip flop) the state of that flip
flop can end up in the 'wrong' state...no different than when timing is
violated on any other signal.
> If yes, then what do I use to reset my double buffer?
>
The double buffer does not need to be 'reset', nor does any other double
buffering of any other async signal for that matter. Think about it for a
second, either those flops are commanding the reset of the chip to 'reset'
for one or two clock cycles after first coming alive even though the
external reset signal is not, this is most likely a 'good' thing since it
gets the part into a known state...or they are not in which case the chip is
properly reflecting the current state of the the external reset signal
(which again is most likely 'good' if you don't have any functional
requirement on the design between when the fpga comes alive and when the
external reset comes in).
If your device and synthesis tools support initializing flops to a known
state at power up (or configuration load) then simply supplying an initial
value to the double buffer flops is a way to force a reset at this time
independent of what the external reset is doing. Something like this...
signal reset_synchronizer: std_ulogic_vector(0 to 1) := "11";
...
process(clock)
begin
if rising_edge(clock) then
reset_synchronizer(1) <= reset_synchronizer(0);
reset_synchronizer(0) <= external_reset;
end if;
end process;
reset_the_device <= reset_synchronizer(1);
Kevin Jennings
Article: 138129Thank you all for informative replies. After reading your posts, I just spend some time looking into the verilog code and xilinx virtex 4 documentation. Following are my findings and some related questions: 1)- BUFG Simple clock in, clock out buffer. It seems that I can remove it for the ASIC implementation as CTS can implement this itself. 2)- BUFIO Simple clock in, clock out buffer. It seems that it can remove this one too for the ASIC implementation without changing the functional behavior and let CTS take care of it. 3)- ODDR Double data rate register. But in the verilog code that I have, it is just being used to forward a copy of the clock to the output (this information can be verified in ug070.pdf - page 324). Note that ODDR has been specifically configured such that D1 input is fixed to 1'b1 and D2 input is fixed to 1'b0. According to the documentation, xilinx recommends using this scheme to forward clocks from the FPGA fabric to the output pins. Now, there are two questions that are disturbing me right now in regards to ODDR. Firstly, what is the reason that xilinx recommend using this scheme and what is the advantage to this approach? Secondly, can somebody tell me if I need this ODDR for my ASIC implementation (for forwarding clock to the output)? 4)- BUFR Clock-in/clock-out buffer with the capability to divide the input clock frequency. In my case, this buffer is just dividing the clock frequency by two. The CE input pin is fixed to 1'b1 and CLR input pin is open. Now, my question is that what is the easiest and most efficient to replace this for ASIC implementation? Can I just use a counter based approach to divide the frequency by two or should I insert another DCM for this one or is there any better way to solve this issue? 5)- BUFMUX_VIRTEX4 A clock buffer with two clock inputs, one clock output, and a select line, which means that it is essentially a clock multiplexer. Note that both the clocks are a factor of one another in this case (i.e. clk1 is 200 MHz and clk2 is 400 MHz). For this one, I can use a simple mux but it will cause glitches at the output at the instant when the 'select line' changes. I found a good resource on the web (http://www.design-reuse.com/articles/5827/ techniques-to-make-clock-switching-glitch-free.html), which present a technique to implement glitch free clock mux but I am sure if this the recommended way to solve this problem. So, any guidance on this one is highly appreciated. 6)- IDELAYCTRL Unfortunately, I don't completely understand the purpose of this module. In the documentation (ug070.pdf - you can easily find this doc by just searching for it on google), the following is stated: The IDELAYCTRL module provides a voltage bias, independent of process, voltage, and temperature variations to the tap-delay line using a fixed-frequency reference clock, REFCLK. This enables very acccurate delay tuning. But how exactly? This just keeps disturbing me as the description is so limited in the documentation. Note that the output pin (RDY) is left open in my case. The documentation also says that the implementation tools allow RDY to be unconnected/ignored. RDY - Ready The ready (RDY) signal indicates when the IDELAY modules in the specific region are calibrated. The RDY signal is deasserted if REFCLK is held High or Low for one clock period or more. If RDY is deasserted Low, the IDELAYCTRL module must be reset. The implementation tools allow RDY to be unconnected/ignored. But just does not make sense to me. What the use of a module whose sole output is just left open? Or how can this module perform calibration with an unconnected RDY port? Lastly, do you think that I need this module for my ASIC implementation? Any feedback is highly appreciated.Article: 138130
Thank you all for informative replies. After reading your posts, I just spend some time looking into the verilog code and xilinx virtex 4 documentation. Following are my findings and some related questions: 1)- BUFG Simple clock in, clock out buffer. It seems that I can remove it for the ASIC implementation as CTS can implement this itself. 2)- BUFIO Simple clock in, clock out buffer. It seems that it can remove this one too for the ASIC implementation without changing the functional behavior and let CTS take care of it. 3)- ODDR Double data rate register. But in the verilog code that I have, it is just being used to forward a copy of the clock to the output (this information can be verified in ug070.pdf - page 324). Note that ODDR has been specifically configured such that D1 input is fixed to 1'b1 and D2 input is fixed to 1'b0. According to the documentation, xilinx recommends using this scheme to forward clocks from the FPGA fabric to the output pins. Now, there are two questions that are disturbing me right now in regards to ODDR. Firstly, what is the reason that xilinx recommend using this scheme and what is the advantage to this approach? Secondly, can somebody tell me if I need this ODDR for my ASIC implementation (for forwarding clock to the output)? 4)- BUFR Clock-in/clock-out buffer with the capability to divide the input clock frequency. In my case, this buffer is just dividing the clock frequency by two. The CE input pin is fixed to 1'b1 and CLR input pin is open. Now, my question is that what is the easiest and most efficient to replace this for ASIC implementation? Can I just use a counter based approach to divide the frequency by two or should I insert another DCM for this one or is there any better way to solve this issue? 5)- BUFMUX_VIRTEX4 A clock buffer with two clock inputs, one clock output, and a select line, which means that it is essentially a clock multiplexer. Note that both the clocks are a factor of one another in this case (i.e. clk1 is 200 MHz and clk2 is 400 MHz). For this one, I can use a simple mux but it will cause glitches at the output at the instant when the 'select line' changes. I found a good resource on the web (http://www.design-reuse.com/articles/5827/techniques-to-make-clock- switching-glitch-free.html), which present a technique to implement glitch free clock mux but I am not sure if this the recommended way to solve this problem. So, any guidance on this one is highly appreciated. 6)- IDELAYCTRL Unfortunately, I don't completely understand the purpose of this module. In the documentation (ug070.pdf - you can easily find this doc by just searching for it on google), the following is stated: The IDELAYCTRL module provides a voltage bias, independent of process, voltage, and temperature variations to the tap-delay line using a fixed-frequency reference clock, REFCLK. This enables very acccurate delay tuning. But how exactly? This just keeps disturbing me as the description is so limited in the documentation. Note that the output pin (RDY) is left open in my case. The documentation also says that the implementation tools allow RDY to be unconnected/ignored. RDY - Ready The ready (RDY) signal indicates when the IDELAY modules in the specific region are calibrated. The RDY signal is deasserted if REFCLK is held High or Low for one clock period or more. If RDY is deasserted Low, the IDELAYCTRL module must be reset. The implementation tools allow RDY to be unconnected/ignored. But this just does not make sense to me. What the use of a module whose sole output is just left open? Or how can this module perform calibration with an unconnected RDY port? Lastly, do you think if I need this module for my ASIC implementation? Any feedback is highly appreciated.Article: 138131
On Fri, 6 Feb 2009 18:04:13 -0800 (PST), mjunaidelahi@gmail.com wrote: >But just does not make sense to me. What the use of a module whose >sole output is just left open? Sole output you can see. This is a biasing block which means there are bias current (or voltage) outputs which are shared by the needy without your awareness. Most probably if you don't instantiate it, its powerdown signals are connected active so that they don't consume power if not needed. >Or how can this module perform >calibration with an unconnected RDY port? It performs calibration by nature of its design. It's basically an analog circuit which usually includes a bipolar transistor to use the base-emittor junction as a temperature compensation mechanism. >Lastly, do you think that I >need this module for my ASIC implementation? If you have a PLL in your ASIC you already have one. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138132
On Feb 6, 9:01=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "axr0284" <axr0...@yahoo.com> wrote in message > > news:f84ecb18-6d3a-484f-adf8-74a66c224bbb@v19g2000yqn.googlegroups.com... > > > I have a clk and a reset coming from an external source to the fpga. I > > cannot be sure of the setup and hold time of the reset signal with > > respect to the clk. > > That makes the reset signal asynchronous to the clock > > > I usually use the double buffer method to synchronize any external > > signal to the clk. > > That's the ticket for synchronizing... > > > I would like to use the reset to reset my internal logic (Everything > > is synchronously reset) but I am wondering if the external reset > > signal need to go through the double buffer too before being sent to > > the logic. > > Yes. =A0The reason is because of what can happen when the external reset = goes > away. =A0While reset is active of course everything gets reset but when r= eset > happens to go away just before or just after the clock (i.e. it when it > violates the setup or hold time of the flip flop) the state of that flip > flop can end up in the 'wrong' state...no different than when timing is > violated on any other signal. > > > If yes, then what do I use to reset my double buffer? > > The double buffer does not need to be 'reset', nor does any other double > buffering of any other async signal for that matter. =A0Think about it fo= r a > second, either those flops are commanding the reset of the chip to 'reset= ' > for one or two clock cycles after first coming alive even though the > external reset signal is not, this is most likely a 'good' thing since it > gets the part into a known state...or they are not in which case the chip= is > properly reflecting the current state of the the external reset signal > (which again is most likely 'good' if you don't have any functional > requirement on the design between when the fpga comes alive and when the > external reset comes in). > > If your device and synthesis tools support initializing flops to a known > state at power up (or configuration load) then simply supplying an initia= l > value to the double buffer flops is a way to force a reset at this time > independent of what the external reset is doing. =A0Something like this..= . > > signal reset_synchronizer: std_ulogic_vector(0 to 1) :=3D "11"; > ... > process(clock) > begin > =A0 if rising_edge(clock) then > =A0 =A0 reset_synchronizer(1) <=3D reset_synchronizer(0); > =A0 =A0 reset_synchronizer(0) <=3D external_reset; > =A0end if; > end process; > reset_the_device <=3D reset_synchronizer(1); > > Kevin Jennings Hmm, makes sense. Thanks for the answer. AmishArticle: 138133
axr0284 wrote: (snip) > I would like to use the reset to reset my internal logic (Everything > is synchronously reset) but I am wondering if the external reset > signal need to go through the double buffer too before being sent to > the logic. > If yes, then what do I use to reset my double buffer? The main reason you need the double buffer for reset (or other signals) is the possibility that different FFs that it connects to will see different clock edges. As for reset, if it goes inactive very close to the clock edge, some parts may go active on one cycle, some on the next. The double buffer only has one FF (connected to the input), which will either go on one clock edge, the next clock edge, or, possibly, go metastable. For the first two cases only one FF is enough. For the third case, the second has an extremely good chance of going on the next cycle. -- glenArticle: 138134
If your looking at Cadence, Mentor and Synopsys, why not also look at Aldec. They have two on offer: activeHDL for Windows, Riviera for Lin/Win/Sun. Functionally, I find they can compare to any of the above and offer a much better price/performance ratio. Their support is fantastic. I've been using riviera myself for maybe three years, mostly for FPGA projects.Article: 138135
If the signals are phase offset, than direction can be determined by: always @(posedge inc_a) dir <= inc_b; 'dir' should be '1' for one way and '0' for the other way. To determine actual rotation can be done via software. If you care to know "how fast" it is being rotated, you will need a small frequency counter in hw. rudiArticle: 138136
Thank you so much for your reply. Can anyone please kindly guide me on the other modules?Article: 138137
On Feb 7, 2:28=A0am, Charles Gardiner <inva...@invalid.invalid> wrote: > If your looking at Cadence, Mentor and Synopsys, why not also look at > Aldec. They have two on offer: activeHDL for Windows, Riviera for > Lin/Win/Sun. > > Functionally, I find they can compare to any of the above and offer a > much better price/performance ratio. Their support is fantastic. I've > been using riviera myself for maybe three years, mostly for FPGA projects= . My only reason not to go with someone other than "big 3" is that the IP that I have is pretty locked down. I can simulate with the named 3 tools, but I'm not sure I can simulate with Aldec. Does Aldec support any encrypted sources?Article: 138138
Hello. Problem is: I define entity comp2 and structural arch. for comp2. In the same VHDL file I define all the used components in structural arch of comp2 (entity + arch). I get syntax error like "std_logic" not defined..but seperatly (when I comment one or the other entity+arch pair) code works !! Below is the example. Where is the problem? Thank U ! entity comp2 is PORT ( A,B : in std_logic_vector (1 downto 0); Z : out std_logic); end comp2; architecture structural of comp2 is ... component komparator port( A,B : in std_logic; Z : out std_logic); end component; begin K1: .... .... end structural; --------------------------------------------------------- entity komparator is PORT( .... end komparator; architecture dataflow of komparator is ..... end dataflow;Article: 138139
OK, I see that it works when I separate the files..but I'm sure that it worked before with more entities in one file... Please explain this.. ?Article: 138140
On Sat, 7 Feb 2009 07:45:59 -0800 (PST), "Mad I.D." wrote:
>I get syntax error like
>"std_logic" not defined..but seperatly (when I comment one or the
>other entity+arch pair) code works !!
>Below is the example.
>
>Where is the problem? Thank U !
It is in the part you did not show us.....
I guess you put
library ieee;
use ieee.std_logic_1164.all;
at the top of the source file. And you probably
assumed that was like a C include file. IT'S NOT!
The library and use statements, known as
"context clauses", apply ONLY TO THE IMMEDIATELY
FOLLOWING DESIGN UNIT. A design unit is a package,
entity, architecture, package body or configuration.
So, for example...
library ieee;
use ieee.std_logic_1164.all;
entity E1 is
port (S: in std_logic); -- OK
end;
entity E2 is
port (T: in std_logic); -- FAIL
end;
The second entity does not know about the context
clauses; they must be re-written just before it:
library ieee;
use ieee.std_logic_1164.all;
entity E1 is
port (S: in std_logic); -- OK
end;
library ieee;
use ieee.std_logic_1164.all;
entity E2 is
port (T: in std_logic); -- OK
end;
However, an architecture inherits all its entity's
declarations, including any context, and so there is
no need to repeat the context clauses before an
architecture. So, if you really want to put two
designs into a file:
library ieee;
use ieee.std_logic_1164.all; -- applies ONLY to E1
entity E1 is
port (S: in std_logic); -- OK
end;
architecture A1 of E1 is
signal Q: std_logic; --OK, std_logic inherited from E1
begin
...
end;
library ieee;
use ieee.std_logic_1164.all; -- needed for E2
entity E2 is
port (T: in std_logic); -- OK
end;
architecture A2 of E2 is
signal Q: std_logic; --OK, std_logic inherited from E2
begin
...
end;
By the way, VHDL syntax/language questions probably belong
on comp.lang.vhdl; but many of the same people hang out
here, so it's OK :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 138141On Feb 7, 5:04=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: /cut Jonathan, thank you very much ! Greeting from Croatia. Ivan.Article: 138142
On Feb 6, 5:35=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 6 Feb 2009 12:56:38 -0800 (PST), jleslie48 wrote:
> >whoa!!!! =A0hold on there! =A0now things are getting interesting!
>
> Yup. =A0You've given me an excuse to waste a lot of time
> playing around with my little Spartan-3 kit :-)
>
> >thanks for the correct syntax:
> >op_MESSAGE & tua("Hello"&CR&LF) & EOM &
>
> There's no reason in principle why the generic
> should not be a string; but, as I pointed out, there
> are some <cough> features of ISE that mean it is
> safer to use an array of 8-bit integers instead.
> So I wrote the tua() conversion function to cast
> a string to an array of 8-bit ints. =A0CR and LF
> are character, not integer constants, so they must
> form part of the STRING (=3Darray of character) that
> is converted by tua().
>
> >you've got a whole mess of computing power built into the
> >entity now,
>
> Not anywhere near enough, yet. =A0I do feel, though, that
> I got a lot more bang per line of code than you did :-)
>
> >and while I'd love to offset this into a picoblaze
> >C programming environment, I won't have that at my disposal
>
> Whyever not? =A0What's the objection to having a soft core
> inside the FPGA to do the slow procedural/sequential stuff?
> No-one is forcing you into TELLING your client it's there...
> and the great joy of an FPGA is that you can also add as
> much custom high-speed hardware as you need, alongside
> the CPU that you need to do the messy-but-slow stuff.
>
> > your state machine built out of VHDL is starting
> > to look mighty pretty to me.
>
> It was deliberately set up as a tutorial teaser - I hope
> you don't find that patronizing, it certainly wasn't
> intended to be so. =A0Unfortunately it does not scale
> particularly well; each time I add new functionality
> to it, its performance degrades measurably. =A0The first
> version (just DELAY and MESSAGE operations) gave me
> up to 120MHz clock speed in my Spartan-3. =A0Adding the
> GOTO and WAIT_FOR_CHAR operations degraded the maximum
> possible speed to about 105MHz. =A0Not a problem so far,
> but clearly some real design effort will be needed if
> you want to add any more serious capabilities.
>
> >first off, I just took a quick dander at the new code,
> >and its set for the 50Mhz clock yes?
>
> yup, sorry, I sent you the wrong version. =A0Well spotted!
>
>
>
> >In my 100Mhz world the line:
> > =A0 =A0 =A0 =A0 =A0IF ( BAUD_COUNT =3D 26 ) THEN
> >in the P4 process:
>
> >P4: =A0PROCESS ( SYSTEM_CLOCK )
> >BEGIN
> > =A0 =A0 IF ( SYSTEM_CLOCK =3D '1' AND SYSTEM_CLOCK'EVENT ) THEN
> > =A0 =A0 =A0 =A0 =A0IF ( BAUD_COUNT =3D 26 ) THEN
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 BAUD_COUNT <=3D 0;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 UART_EN_16_X_BAUD =A0 =A0 =A0 =A0<=3D '1';
> > =A0 =A0 =A0 =A0 =A0ELSE
> [...]
> >should be 54 yes?
>
> Yes. (53, I think, because the count is zero-based.)
> Note I used an INTEGER signal for the count. =A0You may need to
> tweak its declaration to make its range wide enough.
> Better still, declare some constants:
>
> =A0 constant clock_freq_Hz : positive :=3D 100_000_000;
> =A0 constant desired_baud_rate: positive :=3D 115_200;
> =A0 -- let VHDL do the work of computing the divisor!
> =A0 constant baud_rate_divisor: positive :=3D =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock_freq_Hz / (desired_baud_rate * 16);
>
> and then make the declaration and the code match automatically:
>
> =A0 signal baud_count: natural range 0 to baud_rate_divisor-1;
> =A0 ...
> =A0 if baud_count =3D baud_rate_divisor-1 then
> =A0 =A0 baud_count <=3D 0;
> =A0 =A0 UART_EN_16_X_BAUD <=3D '1';
> =A0 else
> =A0 =A0 baud_count <=3D baud_count + 1;
> =A0 ...
>
>
>
> >and this:
> >TRANSMIT_UART : entity work.uart_tx
> > =A0port map
> [...]
> > =A0 =A0 =A0 clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D> =A0 SYSTEM_CLO=
CK
> >isn't the clk here supposed to be:
> >the 1/6th clock?
>
> No. =A0That was absolutely intentional. =A0I wanted the whole
> thing clocked from my single system clock. =A0I didn't see
> the point in your /6 clock, and I still don't. =A0Set the
> Baud-rate divisor to 53 (so you get 100MHz/54) and let
> that do the work.
>
> >I think I'm missing something on understanding how these clocks work.
>
> Possibly. =A0If you want something to operate once every N system
> clocks, it is usually better NOT to use a divided-by-N clock
> directly, but rather to use a divider similar to your baud
> rate prescaler and then to write a process like this...
>
> =A0 if rising_edge(system_clock) then
> =A0 =A0 if (enable_once_per_N_system_clocks =3D '1') then
> =A0 =A0 =A0 =A0do whatever you want;
> =A0 =A0 end if;
> =A0 end if;
>
> Your hardware-oriented co-worker will probably be able to
> help explain why this is so. =A0Please trust me on this.
>
> >"PLEASE DO NOT think about "firing" or "calling" an entity.
> > An entity instance just sits there, doing its thing, for
> > the entire life of the universe. =A0It "fires" on every
> > clock edge, whether you like it or not. =A0"
>
> >Ok, I'm missing something or maybe I'm just not useing the
> >right words.
> >In your ver 1.0, the entity data_gen in JB_Loki_Top
> >generated 1 and only one message output message:
>
> >A
> >abcdefghijkinsertherelmnopqrstuvwxyz12345678pqr
>
> Because its "program" caused it to do so, and then
> had a HALT operation that put it into a stuck state
> so that it made no further progress. =A0It still continues
> to operate on every clock edge - it's just that it is
> in an internal state that happens to make no progress;
> a jump-to-self loop, in software terms.
>
> >now it finished with an op_halt, so I'm guessing that
> >in the details of data gen I'm going to see that HALT
> >render data_gen silent, until reboot time, or I imagine
> >if I give that
> >reset =3D> '0' a real signal to set the output message to
> >resend.
>
> Exactly so.
>
> >Again I think I'm mucking up the language of describing what
> >is the chain of events, but the fact is data_gen put ~something
> >out once and only once, and I'm quite sure their is a way I can have
> >that ~something come out again bases on a change of ~some signal.
>
> See the new version. =A0It works. =A0Try it (with the baud divisor
> appropriately patched to 53 for your higher clock rate).
>
> >I know your going to hate this, but I like that second element of the
> >generic map
> >of data_gen being "the_program". =A0It has established some linear
> >events that are a lot more familiar to me.
>
> That was (more or less) intentional. =A0Think about it for a moment:
> Your hardware is an invariant lump of silicon. =A0It must, inevitably,
> do exactly the same thing on each and every clock cycle. =A0But by
> keeping some state information, and by adjusting the logic's
> outputs and its future state as a function of that state, we
> can make the design progress through a series of states and
> therefore APPEAR to have sequential behaviour. =A0What I gave
> you was an impossibly primitive programmable machine;
> "the_program" is precisely its program, and you can even find,
> explicitly in the design, a PROGRAM COUNTER that steps its way
> through that program. =A0It is not a huge leap of imagination
> from there to a proper general-purpose programmable CPU.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
"Whyever not? What's the objection to having a soft core
inside the FPGA to do the slow procedural/sequential stuff?
No-one is forcing you into TELLING your client it's there...
and the great joy of an FPGA is that you can also add as
much custom high-speed hardware as you need, alongside
the CPU that you need to do the messy-but-slow stuff. "
You might be right, but until I get a better feel for what I
can do in the VHDL world alone, I am in no position to
make that imposition on my customer, and what I haven't
mentioned yet, a third party co-developer.
This system is meant to be an add-on application to an already
existing system made by a competitor. Our competitor has already
fielded equipment and my project is to get my application to run
on their Virtex II FPGA with as little modification as possible to
the legacy system. And as you may guess, these folks did it
all without a picoblaze soft core. Now these folks are a company of
100's, and have been developing FPGA for 8+ years, and have proven
deliverables and production facilities capable of 10 of 1000's of
units.
I'm not in much of position to tell them they need to put a softcore
picoblaze processor on their board. Remember, your talking to the
most knowledgeable person in the field of fpga in my company and you
know how little I know. Now is not the time for me to be pushing
these
kind of design issues. I need to fully explore the capabilities of
the fpga
so if I do insist on a picoblaze soft core, (whatever that is) I have
to be
able to answer why I am dismissing the already existing paradigm. I'm
not prepared to do that right now, and I will be chopped to pieces
(rightfully
so,) in about 10 seconds when the customer calls for a design review
with
all three of us present.
As you might of guessed, this project is not about printing Cindy
Crawfords
measurements. When I built my prototype on a DSP, I was told by
dozens of
folks I had to do it with a FFT. I didn't even know what an FFT was
at the time,
and had to spend 4 months just to get something of an FFT to work, and
then
another month convincing myself that the FFT was not appropriate for
the job.
Only then did I approach my community to put forth my idea of a non
FFT solution.
By then though, I had the knowledge to point out why the FFT failed
and why
my solution solved that issue. I will have to do that with this
situation as well.
Anyway, its the weekend, and I'm gonna put this stuff down for a day
or two,
but I'm very excited about analyzing and moviing forward with this
version.
The rest of you message I'll be addressing on Monday.
Sincerely,
Jonathan Leslie
Article: 138143Aldec does support encrypted Verilog. As far as I remember the encryption they use is compatible to what Synplify (now part of Synopsys) use. I'm not sure about encrypted VHDL, haven't tried it yet. You can get a twenty-day evaluation license from their site. If you need a longer test period, my experience is they are quite open to giving you a node-locked time-limited full license if you contact your local Rep. Poojan Wagh schrieb: > On Feb 7, 2:28 am, Charles Gardiner <inva...@invalid.invalid> wrote: >> If your looking at Cadence, Mentor and Synopsys, why not also look at >> Aldec. They have two on offer: activeHDL for Windows, Riviera for >> Lin/Win/Sun. >> >> Functionally, I find they can compare to any of the above and offer a >> much better price/performance ratio. Their support is fantastic. I've >> been using riviera myself for maybe three years, mostly for FPGA projects. > > My only reason not to go with someone other than "big 3" is that the > IP that I have is pretty locked down. I can simulate with the named 3 > tools, but I'm not sure I can simulate with Aldec. Does Aldec support > any encrypted sources?Article: 138144
On Fri, 6 Feb 2009 15:23:30 -0800 (PST), axr0284 <axr0284@yahoo.com> wrote: >I would like to use the reset to reset my internal logic (Everything >is synchronously reset) but I am wondering if the external reset >signal need to go through the double buffer too before being sent to >the logic. Absolutely. Reset is definitely more sensitive to synchronization issues because it's usually distributed to a very large number of sinks and by its nature getting all blocks out of reset simultaneously is quite important so you should definitely synchronize reset to your internal clock(s). >If yes, then what do I use to reset my double buffer? There is no need. As you know the reset will come active at some point early in the life of the circuit and the clock will be running, these registers will get loaded by the right values externally. Actually this brings up a point. The standard two bit shift register and synchronous reset needs a clock to be active. What I like better is to use a synchronized asynchronous reset which gives you the better of the choices (in my opinion). You get to reset all your circuits asynchronously even with out a clock and release of the reset is done synchronously to your clock so you can make sure the timing is clean. In that case you can still use two registers in shift mode but you can connect the reset to the async reset input of these two flops only and use the output to async reset all your other flops. The input of the first flop should connect to high so when your external reset is activated (goes low) the output becomes low. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138145
On Feb 6, 9:01=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "axr0284" <axr0...@yahoo.com> wrote in message > > news:f84ecb18-6d3a-484f-adf8-74a66c224bbb@v19g2000yqn.googlegroups.com... > > > I have a clk and a reset coming from an external source to the fpga. I > > cannot be sure of the setup and hold time of the reset signal with > > respect to the clk. > > That makes the reset signal asynchronous to the clock > > > I usually use the double buffer method to synchronize any external > > signal to the clk. > > That's the ticket for synchronizing... > > > I would like to use the reset to reset my internal logic (Everything > > is synchronously reset) but I am wondering if the external reset > > signal need to go through the double buffer too before being sent to > > the logic. > > Yes. =A0The reason is because of what can happen when the external reset = goes > away. =A0While reset is active of course everything gets reset but when r= eset > happens to go away just before or just after the clock (i.e. it when it > violates the setup or hold time of the flip flop) the state of that flip > flop can end up in the 'wrong' state...no different than when timing is > violated on any other signal. There can be an issue on the propagation delay for this reset after the double FF sync. But if your design is not all that fast, then this is not so much an issue. As the clock speed increases, the tools will have to work harder to distribute the sync'd reset across the chip. Sometimes the tools will use a global clock line for this. If you find problems having this signal meet timing, you may want to consider localized reset sync circuits rather than one global circuit. This can work if each region controlled by a local reset does not need to be brought out of reset on the same clock cycle as the other regions. This is common in designs rather than the entire device needing to be released from reset at once. There are often many FFs that do not need to be reset at all. All of this depends on your design of course. > > If yes, then what do I use to reset my double buffer? > > The double buffer does not need to be 'reset', nor does any other double > buffering of any other async signal for that matter. =A0Think about it fo= r a > second, either those flops are commanding the reset of the chip to 'reset= ' > for one or two clock cycles after first coming alive even though the > external reset signal is not, this is most likely a 'good' thing since it > gets the part into a known state...or they are not in which case the chip= is > properly reflecting the current state of the the external reset signal > (which again is most likely 'good' if you don't have any functional > requirement on the design between when the fpga comes alive and when the > external reset comes in). I don't agree that the reset or other buffer FFs don't need to be reset by something other than the external reset signal. If the FF reset is an async input, then it will be held in the reset state as soon as the chip is configured. But if the reset is a sync input to the FF, it will not take effect until a rising clock edge. The chip global set/reset signal will be holding the FF in a state which may be different from the state the external reset will put it on the next clock edge. So the initial state of the FF needs to be established or you can get spurious signals on configuration. > If your device and synthesis tools support initializing flops to a known > state at power up (or configuration load) then simply supplying an initia= l > value to the double buffer flops is a way to force a reset at this time > independent of what the external reset is doing. =A0Something like this..= . > > signal reset_synchronizer: std_ulogic_vector(0 to 1) :=3D "11"; > ... > process(clock) > begin > =A0 if rising_edge(clock) then > =A0 =A0 reset_synchronizer(1) <=3D reset_synchronizer(0); > =A0 =A0 reset_synchronizer(0) <=3D external_reset; > =A0end if; > end process; > reset_the_device <=3D reset_synchronizer(1); Unfortunately, that is a big if. I think it is becoming more common, but it is not universal. The other alternative is not portable between chips, but most families allow a GSR type component to be instantiated which can be used to drive an async input to the FF. Then all FFs coded this way will have a known initial state regardless of the tool used. The GSR instantiation will need to be changed when porting to different brands/families of FPGAs. I typically use an external reset to async control a few "reset" FFs used to sync control the rest of the design. These "reset" FFs can be duplicated around the design if it is large to prevent the sync reset delays from affecting the speed of the design. Of course, each region controlled by separate "reset" FFs must be able to operate correctly if started a clock or two out of step with the rest of the design. RickArticle: 138146
Hi, I have lots (thousands) of Altera EPX880 (FlashLogic). This device is obsolete and the only software I know that can be used to design it is PLDShell Plus V5.1. Anybody know where to download it please...??? I contacted Altera they said they don't have it anymore... Thanks and best regards, HartArticle: 138147
On Sat, 7 Feb 2009 17:14:38 -0800 (PST), hartono.setiono@gmail.com wrote: >Hi, I have lots (thousands) of Altera EPX880 (FlashLogic). This device >is obsolete and the only software I know that can be used to design it >is PLDShell Plus V5.1. Anybody know where to download it please...??? >I contacted Altera they said they don't have it anymore... There seems to be a downloadable copy of version 4.0 here: http://www.pads.uwaterloo.ca/~wdbishop/ece324/PLDshell.html -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138148
> There seems to be a downloadable copy of version 4.0 here:http://www.pads.uwaterloo.ca/~wdbishop/ece324/PLDshell.html > > -- Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Serviceshttp://www.dspia.com Thanks, I have downloaded it ( I also got V5.0)... But it seems that the only version that support it is V5.1 HartArticle: 138149
Eric wrote: > I've been using a heavily-hacked-together version of xc3sprog with the > Xilinx Parallel cable IV for a while now under linux. However, more > and more machines lack parallel ports, and I'm looking for an > alternative. The Xilinx Platform Cable (2) USB was an option, except > that setup is a bit of a pain, and there don't appear to be any Free > tools for programming devices with it. > > I like to leave JTAG adaptors around at customers' sites such that I > can try a bit of remote debugging before I end up on site, but this is > getting increasingly difficult without the parallel ports. I also > wouldn't want to be installing the full ISE suite on customers > machines if I could avoid it. I've not had any success using USB-to- > parallel-port converters, either. > > Given these, what do people recommend for programming their Xilinx > devices? I'd like the following: > 1. Works close-to-out-of-the-box under linux > 2. Cheap (<$250) > 3. Non-horrible software that works under 32- and 64-bit OSes, ideally > with source > 4. the ability to get at the USERn registers from the FPGA, either > from the command line or an API. > 5. ships out-of-the-box with the xilinx 2x7 2mm header for JTAG. > > Has anyone seen any options that might get me close to this? > > Thanks, > ...Eric Eric, Digilent (www.digilentinc.com) sells a nice usb to 6 pin cable for $37.95. Problem is it only works with their windoze software. Would be nice if they supported linux. John Eaton
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