Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 134125

Article: 134125
Subject: Re: The littlest CPU
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 26 Jul 2008 22:16:11 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> I may need to add a CPU to a design I am doing.  I had rolled my own
> core once with a 16 bit data path and it worked out fairly well.  But
> it was 600 LUT/FFs and I would like to use something smaller if
> possible.  

I think an interesting architecture would be a Turing machine. It was
proved that a 7-state 4-symbol machine is an universal Turing machine (can
be reduced even more, if you figure out how to use Wolfram's rule 110,
which can be emulated by a smaller Turing machine, to implement arbitrary
computer programs). This means a lookup table of 28 entries, where each
entry is 6 bits, and an up-/down counter for accessing the memory,
organized in 2 bits words, is sufficient. I would use another BRAM for the
lookup table, then the number of LUTs should be very low to implement the
Turing machine.

Of course, the maschine would be unbelievable slow and would need some
major work to implement a GCC backend for it, but you could even implement
it with a fistful of standard logic ICs :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 134126
Subject: Re: Creating new operators
From: Paul Taylor <pt@false_email.co.uk>
Date: 26 Jul 2008 22:21:34 +0100
Links: << >>  << T >>  << A >>
On Sat, 26 Jul 2008 06:04:01 -0700, rickman wrote:

>   BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
> 
> This is what I expect a concurrent statement to look like, not to
> mention that it represents exactly the image I had in my head and on
> the whiteboard, making it much easier to write.
> 
> I am sure there are those who disagree and much prefer the verbose
> process.  Maybe I'm just not cut out for the regimen of VHDL.

I'm not _entirely_ cut out for the regimen of VHDL, which is why I have
the imaginary BerryHDL which is considerably more terse than VHDL, eg:

http://myweb.tiscali.co.uk/pault/example.html

The main thrust of it is to represent schematic type blocks efficiently
with text. A general mux is as follows:

node muxOutput = [a, b, c, d][sel];

That's a mux with four inputs. Your example would be:

node BERTEn = BERTSel & [!GenPOSSel, !SyncPOSSel][GenEn];

Which I think is better than a ternary type operator.

Doesn't python allow you to do something like that? You may find that
MyHDL will do something similar to the above? And MyHDL isn't imaginary.

Regards,

Paul.

Article: 134127
Subject: Opencores DDR2 SDRAM controller with spartan3e starter board
From: blinkenlights <Klaus.Rindtorff@gmail.com>
Date: Sat, 26 Jul 2008 14:36:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Ok, tried it for weeks, now I give up and ask for help...
I have a Spartan S3E starter kit board with a 46V32M16 DDR2 SDRAM on
it. My design needs to read and write 32 bit words to SDRAM. I tried
MIG 2.2 from the Xilinx coregen tools, but couldn't get it to work.
Finally I found a controller design originally written by Markus Lemke
and then modified for the Spartan S3E by David Ashley at Opencores.org
(thanks to both!). The testbench included was simulated and
synthesized fine, and works with the board as well, as far as I can
tell from the LEDs.
However, when used in my design, it fails. The design is first
writing, then reading several hundred words of data from the SDRAM.
The first word reads back ok, but all others are zero. I can see this
in the simulation as well as when stopping the clock and examining the
registers of my design.
Has anybody successfully used the Opencores DDR2 SDRAM controller on
the S3E starter board?

Article: 134128
Subject: Re: Opencores DDR2 SDRAM controller with spartan3e starter board
From: Gabor <gabor@alacron.com>
Date: Sat, 26 Jul 2008 15:13:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 26, 5:36 pm, blinkenlights <Klaus.Rindto...@gmail.com> wrote:
> Ok, tried it for weeks, now I give up and ask for help...
> I have a Spartan S3E starter kit board with a 46V32M16 DDR2 SDRAM on
> it. My design needs to read and write 32 bit words to SDRAM. I tried
> MIG 2.2 from the Xilinx coregen tools, but couldn't get it to work.
> Finally I found a controller design originally written by Markus Lemke
> and then modified for the Spartan S3E by David Ashley at Opencores.org
> (thanks to both!). The testbench included was simulated and
> synthesized fine, and works with the board as well, as far as I can
> tell from the LEDs.
> However, when used in my design, it fails. The design is first
> writing, then reading several hundred words of data from the SDRAM.
> The first word reads back ok, but all others are zero. I can see this
> in the simulation as well as when stopping the clock and examining the
> registers of my design.
> Has anybody successfully used the Opencores DDR2 SDRAM controller on
> the S3E starter board?

I would think if you can see this in simulation you could get to
the bottom of it fairly quickly.  I assume you are using the
Micron simulation model for the SDRAM part?  With the debug
option set you can see what the memory model thinks you are
writing or reading.  If it says zeroes are going in, then it makes
sense zeroes would come out.  If it shows something more
like you expected going in, then either you should see the same
thing coming out or some indication that you're not accessing
the data you thought you were.  If the memory model seems
to be reading the data correctly, something is broken further
up the food chain (in the opencores module).

Any more on why the MIG core didn't work?  I would think
that should be pretty easy to get running.

Regards,
Gabor

Article: 134129
Subject: Re: Opencores DDR2 SDRAM controller with spartan3e starter board
From: blinkenlights <Klaus.Rindtorff@gmail.com>
Date: Sat, 26 Jul 2008 15:36:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Yes, I am using the MICRON model, but I didn't expect the memory to be
simulated as well. You mentioned a debug option. Am I missing
something?
I am seeing tristate Z values in the simulation instead. The hint on
the zeros in the simulation is that just before the high and low parts
of the data are latched they change their value to zero. Sounds easy
to spot, but didn't help me to find the reason. In the implementation
I can trace the incoming zeros using my own debug mode in the
processor design.
The MIG generated controller was just too complicated, and the S3E
board reference design in VHDL had the wrong burst length for my
design.

Article: 134130
Subject: Re: Creating new operators
From: Mike Treseler <mtreseler@gmail.com>
Date: Sat, 26 Jul 2008 21:02:22 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

>    BERTEn <=     BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel);
> 
> Is that more clear?

Yes.
In any case, I agree with KJ on this one.
Take it out of time with a function:

   function sel (choice : boolean;
                 a, b   : std_logic_vector)
      return std_logic_vector is
      begin
         if choice then return a; else return b; end if;
   end function sel;


  -- Mike Treseler

Article: 134131
Subject: Re: Spartan-3A DSP 1800A Dev Board JTAG Cable and Programming
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 27 Jul 2008 02:50:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Scott

There are a number of companies including ourselves doing Cable III
look-alike cables. If you hunt around can get hold of the Xilinx
schematic and even build your own.

Cable III look-alike cables tend not be as fast, or robust, as Xilinx
Cable IV / USB solutions but work for most people assuming they have a
parallel port available which is often a problem. We have offerings
for the standard 2x7 2mm header (Prog2) and adaptors for a couple 6x1
headers that we also use in our products. Price of these are GBP=A310 /
US$20 / 15 Euros plus taxes and shipping.

Some details on our store http://www.enterpoint.co.uk/store/erol.html.
I'll also warn that we will have longer response and delivery times in
August due to staff holidays.

John Adair
Enterpoint Ltd. - Home of Drigmorn1. The Low Cost Development Board.


On 26 Jul, 18:56, no.s...@gte.net (Scott Gravenhorst) wrote:
> On Sat, 26 Jul 2008 09:38:02 -0700 (PDT), ghelbig <ghel...@lycos.com>
> wrote:
>
>
>
>
>
> >On Jul 26, 5:37 am, no.s...@gte.net (Scott Gravenhorst) wrote:
> >> I have a Spartan-3A DSP 1800A development board which comes with no
> >> cable. =A0I understand that Xilinx makes a cable for $150 that works
> >> with iMPACT. =A0There is also a 6 pin JTAG conntector on the board.
>
> >> I already know that the Digilent JTAG-USB cable will NOT work with
> >> either iMPACT nor Adept. =A0Communication with Digilent indicates that
> >> they may support this FPGA in the future, but it is currently not
> >> supported. =A0I've also tried xilprg which does not yet support this
> >> FPGA.
>
> >> I would like to find a more cost effective method than the Xilinx
> >> cable. =A0I've read comments here and elsewhere that the Digilent
> >> Parallel III cable is a clone of the Xilinx cable. =A0Does anyone know
> >> if Will this cable (Digilent Parallel III) works with this board and
> >> iMPACT or any other Windows based FPGA programmer software? =A0Or is
> >> there a better solution?
>
> >> Many thanks.
>
> >> -- ScottG
>
> >I started down that path; it bothered me to pay $200 for a simple USB
> >dongle.
>
> >The Xilinx programmer "just works". =A0If it doesn't, my friendly local
> >FAE will fix that. I figured that I would be busy enough working on
> >the real parts of the project that the half-week (or so) spent looking
> >for a lower-cost replacement was a poor use of my time.
>
> >And think about it: =A0The board is $1100,
>
> It's now $295. =A0With WebPACK ISE (which _will_ work with this FPGA),
> it's still $295. =A0If the price of the board were still $1095 (which I
> saw a while back on Xilinx), I probably never would have purchased the
> board. =A0So you see, it wasn't that expensive and another $200 for a
> cable or dongle is about 66% of the price of the board! =A0Hence why I'm
> trying to do this a bit more economically. =A0
>
> Even if a parallel cable or other less expensive method is slower -
> I'd be happy. =A0And lack of ChipScope doesn't matter to me. =A0I'm not
> doing this for some corporate project with a big budget, this is for
> me, personally, for self education and personal projects.
>
>
>
> >EDK adds $500, and the DSP
> >bundle is another $1000. =A0And if you want full ISE with simulator, add
> >$3500. =A0Even with WebPack, that's $3600, percentage-wise, the
> >programmer doesn't add that much.
>
> >Just my opinion,
> >G.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -


Article: 134132
Subject: Re: Opencores DDR2 SDRAM controller with spartan3e starter board
From: blinkenlights <klaus.rindtorff@googlemail.com>
Date: Sun, 27 Jul 2008 03:20:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
And of course the MT46V32M16 is DDR SDRAM, not DDR2.

Article: 134133
Subject: Re: Creating new operators
From: diogratia <diogratia@gmail.com>
Date: Sun, 27 Jul 2008 05:51:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 27, 1:04 am, rickman <gnu...@gmail.com> wrote:
> On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com>
> wrote:

>   BERTEn <=  '0' when BERTSel = '0' else
>                 not SyncPOSSel when GenEn = '0' else
>                 not GenPOSSel;
>
> I don't think that the diagram I drew comes to mind when you see this
> code.  Maybe a process with an IF statement would be slightly more
> clear, but the verbosity presents an obfuscation of its own from the
> "clutter" created.
>
> process (  BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
>   if (BERTSel = '0') then
>     BERTEn <=        '0';
>   elsif (GenEn = '0') then
>     BERTEn <=        not SyncPOSSel
>   else
>     BERTEn <=        not GenPOSSel;
>   end if;
> end process;
>
> The clutter is from the sheer size of the code.  The first three line
> example is a bit obtuse, the 9 line example is large enough to make it
> hard to see the rest of the code and so to see how it fits into the
> big picture.  Compare the two examples to this code...
>
>   BERTEn <=  BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>
> This is what I expect a concurrent statement to look like, not to
> mention that it represents exactly the image I had in my head and on
> the whiteboard, making it much easier to write.
>

There's also combinatoric expression in a concurrent statement:

   BERTEn <= (BERTSel  and not GenEN and not SyncPOSSel) or
	     (BERTSel  and     GenEN and not GenPOSSel );

This also shows it's a two input multiplexer with a select line and an
enable, which you could do as a block statement, component or
subprogram and invoke like a component or subprogram.

Seriously, you can always write a preprocessor that recognizes your
preferred syntax and translates it into correct VHDL for analysis.
Some of us are old enough to remember WATFOR and the like, adding
things like case statements to Fortran.

A preprocessor for the above preferred syntax could recognize a
concurrent signal assigment with a right hand side containing '?' and
':' in matching numbers..The associativity precedence can be a right
royal pain, requiring lookahead or recursion.

For full integration with a tool environment you might need to write
an analyzer wrapper that invokes the preprocessor, as is done for
cpp.  In and environment where you can use make files, you can hide
the complexity there.

Instant language syntax extensions.












Article: 134134
Subject: vhdl code for debouncing push button
From: Zhane <me75@hotmail.com>
Date: Sun, 27 Jul 2008 06:41:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
are there any vhdl codes that are available for free to debounce the
pushbutton on my spartan 3E?

I require the push button to generate only 1 clock for 50mhz only upon
release.

I've gotten some code from the net but aint sure if it does what I
need....

==============================================================

library ieee;
use ieee.std_logic_1164.all;

entity debouncer is
	port (clk,reset: in std_logic; -- clk frequency = 50Mhz
			pb: in std_logic;
			pb_debounced: out std_logic
			);
end entity debouncer;

architecture rtl of debouncer is
	signal count500000 : integer range 0 to 499999;
	signal clk_100Hz: std_logic;
	signal pb_sampled: std_logic;
begin

div_100Hz: process(clk,reset) is
begin
	if reset ='1' then
		clk_100Hz <= '0';
		count500000 <= 0;
	elsif rising_edge(clk) then
		if count500000 = 499999 then
			count500000 <= 0;
			clk_100Hz <='1';
		else
			count500000 <= count500000 + 1;
			clk_100Hz <='0';
		end if;
	end if;
end process div_100Hz;

debounce_pb: process(clk) is
begin
	if rising_edge(clk) then
		if clk_100Hz ='1' then
			if pb = pb_sampled then
				pb_debounced <= pb;
			end if;
			pb_sampled <= pb;
		end if;
	end if;
end process debounce_pb;

end architecture rtl;
==================================================

pls advise

Article: 134135
Subject: Re: Creating new operators
From: rickman <gnuarm@gmail.com>
Date: Sun, 27 Jul 2008 07:40:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 26, 3:16 pm, Frank Buss <f...@frank-buss.de> wrote:
> rickman wrote:
> > The process based description is not immediately clear to me at first
> > glance.  I *do* have to think about it since that is not what I
> > picture in my mind.  I visualize a MUX controlled by GenEn feeding an
> > AND gate with BERTSel.  The Verilog like assignment maps exactly to
> > that visualization.  The others require me to mentally convert the
> > syntax from and IF statement to the AND gate not to mention the length
> > of the code.
>
> For me it is more like a tree: The process form with the nested if
> statements forms a tree, which I can see immediatly (maybe because I'm used
> to program in Java and C), where the two main branches are selected by
> BERTSel and the second branch is the mux. This is more clear for me than
> using an AND gate.

You may read the code easily, but that is not what I was doing.  I was
writing the code.  I had the idea of what I wanted to write expressed
as a diagram.  It should have been a simple matter to write code that
directly expressed that simple diagram.  Instead, I had to work the
logic around to fit the constructs available in the language.

This is completely ignoring the difference between some 8 or 10 lines
of code in the process vs. a single line of perfectly clear code using
the select statement.

Rick

Article: 134136
Subject: Re: vhdl code for debouncing push button
From: rickman <gnuarm@gmail.com>
Date: Sun, 27 Jul 2008 07:49:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think whether this code works for you depends on the push button.  I
have some tactile switches that initially showed *no* bouncing.  After
just a week or two of use they bounce so badly that it is impossible
to debounce them.

The best switch to debounce is a double throw switch.  The FF stays in
a given state until the other contact is made.  Very simple, but it
requires two inputs and a more complex switch.

Rick


On Jul 27, 9:41 am, Zhane <m...@hotmail.com> wrote:
> are there any vhdl codes that are available for free to debounce the
> pushbutton on my spartan 3E?
>
> I require the push button to generate only 1 clock for 50mhz only upon
> release.
>
> I've gotten some code from the net but aint sure if it does what I
> need....
>
> ==============================================================
>
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity debouncer is
>         port (clk,reset: in std_logic; -- clk frequency = 50Mhz
>                         pb: in std_logic;
>                         pb_debounced: out std_logic
>                         );
> end entity debouncer;
>
> architecture rtl of debouncer is
>         signal count500000 : integer range 0 to 499999;
>         signal clk_100Hz: std_logic;
>         signal pb_sampled: std_logic;
> begin
>
> div_100Hz: process(clk,reset) is
> begin
>         if reset ='1' then
>                 clk_100Hz <= '0';
>                 count500000 <= 0;
>         elsif rising_edge(clk) then
>                 if count500000 = 499999 then
>                         count500000 <= 0;
>                         clk_100Hz <='1';
>                 else
>                         count500000 <= count500000 + 1;
>                         clk_100Hz <='0';
>                 end if;
>         end if;
> end process div_100Hz;
>
> debounce_pb: process(clk) is
> begin
>         if rising_edge(clk) then
>                 if clk_100Hz ='1' then
>                         if pb = pb_sampled then
>                                 pb_debounced <= pb;
>                         end if;
>                         pb_sampled <= pb;
>                 end if;
>         end if;
> end process debounce_pb;
>
> end architecture rtl;
> ==================================================
>
> pls advise


Article: 134137
Subject: Re: vhdl code for debouncing push button
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 27 Jul 2008 17:07:07 +0200
Links: << >>  << T >>  << A >>
Zhane wrote:

> debounce_pb: process(clk) is
> begin
> 	if rising_edge(clk) then
> 		if clk_100Hz ='1' then
> 			if pb = pb_sampled then
> 				pb_debounced <= pb;
> 			end if;
> 			pb_sampled <= pb;
> 		end if;
> 	end if;
> end process debounce_pb;

Usually every unsychronized external input should be latched. A switch
doesn't change very often, so the probality to cause problems is very low,
but I would add another signal, something like this:

debounce_pb: process(clk) is
begin
	if rising_edge(clk) then
		if clk_100Hz ='1' then
			if pb_latched = pb_sampled then
				pb_debounced <= pb_latched;
			end if;
			pb_sampled <= pb_latched;
			pb_latched <= pb;
		end if;
	end if;
end process debounce_pb;

The rest of the code looks ok. It filters single spikes, which are shorter
than 20ms and filters any bouncing sequence shorter than 10ms. I would add
a generic parameter for specifying the clock frequency to make the entity
more resuable.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 134138
Subject: Cyclone III passive serial config issue
From: Paul Urbanus <urbpublic@hotmail.com>
Date: Sun, 27 Jul 2008 10:25:56 -0500
Links: << >>  << T >>  << A >>
Hi, my name is Paul, and I'm a long-time Xilinx user.  (in your best AA 
voice, now: "Hi Paul") I'm doing my first Altera design using a Cyclone 
III. The design has a very wide video output bus which drives some 
ASICs, so the VCCIO voltage is set to 3.0 so the internal series 
terminations can be used.

I believe I understand the interface rules when VCCIO = 3.0V, but now 
the relationship between the configuration modes and VCCIO for a given 
configuration banks is a bit unclear.

I plan to use one of the Passive Serial configuration modes and Table 
10-1 in the Cyclone III Handbook shows the following.

     Config. Scheme       | MSEL[3:0] | Config. Voltage Std
-------------------------+-----------+--------------------
Passive Serial Standard  |    0000   |  3.3/2.5 V
Active Serial Standard   |    0010   |  3.3 V
Active Parallel 16 Fast |    0101   |  3.3 V
Active Parallel 16 Fast |    0110   |  1.8 V
Active Parallel 16      |    0111   |  3.3 V
Active Parallel 16      |    1000   |  1.8 V
Active Parallel 16      |    1011   |  3.0/2.5 V
Passive Serial Fast      |    1100   |  3.3/2.5 V
Active Serial Fast       |    1101   |  3.3 V
Fast Passive Par. Fast   |    1110   |  3.3/2.5 V
Fast Passive Par. Fast   |    1111   |  1.8/1.5 V
JTAG-based configuration |    XXXX   |   

X = Valid low or high level


 From the above table, it appears that the MSEL pins have different 
values for the same configuration mode, with the only difference being 
the VCCIO level.

What is unclear (or rather, a potential problem) is that for both 
passive serial modes, the configuration voltage standard is 3.3/2.5V. 
Note that 3.0V is conspicuously absent for the passive serial modes. In 
fact, the only configuration mode which lists 3.0V is Active Parallel.

Does this mean that I can't use any configuration mode except Active 
Parallel (and JTAG) if all of my VCCIO levels are at 3.0V?


TIA

Paul

Article: 134139
Subject: Re: Creating new operators
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Sun, 27 Jul 2008 17:14:31 +0100
Links: << >>  << T >>  << A >>
On Sun, 27 Jul 2008, diogratia wrote:

|------------------------------------------------------------------------|
|"[..]                                                                   |
|                                                                        |
|Seriously, you can always write a preprocessor that recognizes your     |
|preferred syntax and translates it into correct VHDL for analysis.      |
|Some of us are old enough to remember WATFOR and the like, adding       |
|things like case statements to Fortran.                                 |
|                                                                        |
|A preprocessor for the above preferred syntax could recognize a         |
|concurrent signal assigment with a right hand side containing '?' and   |
|':' in matching numbers..The associativity precedence can be a right    |
|royal pain, requiring lookahead or recursion.                           |
|                                                                        |
|For full integration with a tool environment you might need to write    |
|an analyzer wrapper that invokes the preprocessor, as is done for       |
|cpp.  In and environment where you can use make files, you can hide     |
|the complexity there.                                                   |
|                                                                        |
|Instant language syntax extensions."                                    |
|------------------------------------------------------------------------|

I would prefer to use one tool which supports the language I am using
instead of a preprocessor which supports some of it by replacing
strings by other strings to be given to another tool which tries to
cope with another part of the language.

Would you suggest that someone who does not want to use such a
preprocessor should write an entire extended language frontend
(perhaps written by reusing code from a full proper BNF-based VHDL
frontend)?

Article: 134140
Subject: Re: Creating new operators
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Sun, 27 Jul 2008 17:27:29 +0100
Links: << >>  << T >>  << A >>
On Sat, 26 Jul 2008, Brian Drummond wrote:

|------------------------------------------------------------------------|
|"On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley                   |
|<jonathan.bromley@MYCOMPANY.com> wrote:                                 |
|                                                                        |
|>On Fri, 25 Jul 2008 22:46:26 -0700 (PDT), rickman wrote:               |
|>                                                                       |
|>>In VHDL an operator can be overloaded.  But can a new operator be     |
|>>created?  There is more than once I would like to use the very concise|
|>>notation available in Verilog such as the select operator.  Is there a|
|>>way to create the selection operator in VHDL?  Looking at the         |
|>>structure, I guess it just doesn't fit the mold for VHDL with three   |
|>>operands.                                                             |
|>                                                                       |
|>No, you can't create new VHDL operators.  Apart from                   |
|>introducing new pseudo-keywords into the language, this would          |
|>also raise the nasty difficulty that operators have many other         |
|>hidden properties apart from their function signature.                 |
|>Operators have precedence and associativity.  And of course,           |
|>as you say, VHDL has no notion of 3-ary operators like ?:              |
|>in any case.                                                           |
|>                                                                       |
|>Algol-68 tried to make it possible to create arbitrary                 |
|>user-defined operators, and it was VERY complicated...                 |
|                                                                        |
|More dynamic OO languages support arbitrary operator creation; Smalltalk|
|would be an example, or the old Linn Lingo.                             |
|                                                                        |
|It's not VERY complicated _in_that_environment_ where static typing is  |
|almost non-existent (strong typing can be rigorous, but implemented at  |
|runtime)"                                                               |
|------------------------------------------------------------------------|

Dynamic strong typing instead of static strong typing is not very
useful. Smalltalk programs crash. Lisp programs crash. Statically
typed programs also crash, but are less prone to having their crashes
caused by things which could have been detected during compilation.

|------------------------------------------------------------------------|
|" BUT ...                                                               |
|(1) you are limited to the creation of binary operators; so ?: is still |
|tricky, to put it mildly, and"                                          |
|------------------------------------------------------------------------|

I do not remember whether this is true with PROLOG.

|------------------------------------------------------------------------|
|"(2) operator precedence is usually predetermined and deeply embedded in|
|the parser."                                                            |
|------------------------------------------------------------------------|

In Prolog one can choose any precedence and any location (viz. prefix;
infix; and postfix) and probably (but I do not remember for sure) any
associativity for user-defined operators (and even worse, allows these
to be redefined for standard operators).

|------------------------------------------------------------------------|
|" The above languages solved this problem by allocating                 |
|precisely one precedence level to all operators - in other words, use   |
|brackets."                                                              |
|------------------------------------------------------------------------|

A good choice. Operators which are otherwise identical have different
precedences in different languages so people shall make mistakes
according to what they are used to.

|------------------------------------------------------------------------|
|"[..]                                                                   |
|                                                                        |
|But anyway I suspect you'd have to destroy VHDL to add extensible       |
|operators...                                                            |
|                                                                        |
|[..]"                                                                   |
|------------------------------------------------------------------------|

I do not approve of user-defined operators. Operators at all are
debatable. Functions or conditional statements should be enough.

Thank you for the interesting observations.

Regards,
Colin Paul Gloster

Article: 134141
Subject: Re: Opencores DDR2 SDRAM controller with spartan3e starter board
From: Gabor <gabor@alacron.com>
Date: Sun, 27 Jul 2008 11:22:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 27, 6:20 am, blinkenlights <klaus.rindto...@googlemail.com>
wrote:
> And of course the MT46V32M16 is DDR SDRAM, not DDR2.

What I meant about the debug option is actually a debug parameter
in the model.  If set to 1 it turns on a lot of $display stuff to let
you know what operations are being performed on the memory.
With debug set to zero, you only get error messages.

I agree that the MIG core is much more complex than it needs
to be, however if it just works (which seems to be the case for
many users) you can just think of it as a big black box.  By the
way I assume you actually used the correct settings (DDR vs
DDR2) when you tried it out?

In the simulation you say the data changes just before it is latched.
You mean that the correct data was on the DQ lines and suddenly
went low just before the clock edge on DQS?

Article: 134142
Subject: Re: vhdl code for debouncing push button
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 28 Jul 2008 07:51:29 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> I think whether this code works for you depends on the push button.  I
> have some tactile switches that initially showed *no* bouncing.  After
> just a week or two of use they bounce so badly that it is impossible
> to debounce them.
> 
> The best switch to debounce is a double throw switch.  The FF stays in
> a given state until the other contact is made.  Very simple, but it
> requires two inputs and a more complex switch.

Yes, a SPCO switch (classic Micro-switch action) is more complex,
as it has an extra contact, but I cannot see
the 'requires two inputs' in any I have used ?

Wire one end to Vcc, one to GND, and the contact to the Pin,
and enable the Pin-Keep if you like, and you are done.

Did you mean a SET/RESET action, which needs two pins, and two
resistors (can be pin-pulldowns) ?

SPCO switches should be the default on demo-boards, as you can
also clock off them...

-jg


Article: 134143
Subject: Re: vhdl code for debouncing push button
From: "Fred" <fred@nospam.com>
Date: Mon, 28 Jul 2008 01:35:02 +0100
Links: << >>  << T >>  << A >>

"Zhane" <me75@hotmail.com> wrote in message 
news:ab0ae7bc-b7a5-47bd-bc2e-33d350f3026a@n33g2000pri.googlegroups.com...
> are there any vhdl codes that are available for free to debounce the
> pushbutton on my spartan 3E?
>
> I require the push button to generate only 1 clock for 50mhz only upon
> release.
>
> I've gotten some code from the net but aint sure if it does what I
> need....
>
> ==============================================================
>
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity debouncer is
> port (clk,reset: in std_logic; -- clk frequency = 50Mhz
> pb: in std_logic;
> pb_debounced: out std_logic
> );
> end entity debouncer;
>
> architecture rtl of debouncer is
> signal count500000 : integer range 0 to 499999;
> signal clk_100Hz: std_logic;
> signal pb_sampled: std_logic;
> begin
>
> div_100Hz: process(clk,reset) is
> begin
> if reset ='1' then
> clk_100Hz <= '0';
> count500000 <= 0;
> elsif rising_edge(clk) then
> if count500000 = 499999 then
> count500000 <= 0;
> clk_100Hz <='1';
> else
> count500000 <= count500000 + 1;
> clk_100Hz <='0';
> end if;
> end if;
> end process div_100Hz;
>
> debounce_pb: process(clk) is
> begin
> if rising_edge(clk) then
> if clk_100Hz ='1' then
> if pb = pb_sampled then
> pb_debounced <= pb;
> end if;
> pb_sampled <= pb;
> end if;
> end if;
> end process debounce_pb;
>
> end architecture rtl;
> ==================================================
>
> pls advise

There are a few methods of debouncing switches.

One way of thinking is what's the minimum period between switch operations, 
then having a timer-counter to ensure that another swich operations can't 
occur during this period.

constant integer max := xxxxx;

if reset then
    timer_count = 0;
    pb_debounced = '0';

else rising_edge(clk) then
    if pb = '0' then
        if timer_count = max then
            pb_debounced <= '1';
            timer_count <= 0;
        else
            timer_count <= 0;
        end if;
    else
        if timer_count = max then
            pb_debounced <= '1';
        else
            timer_count <= timer_count +1;
        end if;
    end if;
end if;

E&OE! 



Article: 134144
Subject: Re: Prevent synthesis optimizations/simplifications in Xilinx-ISE
From: giorgos.puiklis@gmail.com
Date: Sun, 27 Jul 2008 22:50:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 25, 10:13 pm, "blak...@gmail.com" <blak...@gmail.com> wrote:
> On Jul 25, 8:23 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Jul 25, 6:12 am, giorgos.puik...@gmail.com wrote:
>
> > > Hello,
>
> > > I want to implement a VHDL design in a Spartan3 device. Some
> > > components of the design use cascaded inverters to produce one-shots
> > > (short pulses). Upon synthesis, Xilinx-ISE simplifies the cascaded
> > > inverters (e.g. if 6 inverters are cascaded it simply removes them
> > > all). This alters the functionality of the design.
>
> > > How can I configure ISE so that it does not perform such
> > > simplifications (preferably per block, but if this is not possible for
> > > the whole design)?
>
> > > Thank you in advance guys!
>
> > > Regards,
> > > George
>
> > Unfortunately simple logic elements like inverters and gates will
> > always be mapped into LUT's regardless of any KEEP attributes on
> > the intermediate nets.  You can however create such delay elements
> > by instantiating primitives like LUT's with the appropriate INIT
> > attributes to generate the functions you want.  Look at the
> > Libraries guide to see your options for LUT instantiation.
>
> > I should add that this sort of design practice is generally frowned
> > upon in FPGA's, especially since there is a very wide variance in
> > delay due to process and temperature, and a possibly even wider
> > variance from build to build due to routing if you don't hand
> > place your delay elements.  Usually you can use synchronous
> > techniques to create pulses and with a sufficiently fast clock
> > rate you can often ignore the discrete timing effects of the
> > synchronous pulse generator.
>
> > Regards,
> > Gabor- Hide quoted text -
>
> > - Show quoted text -
>
> I know exactly what you need
> use the attribute KEEP to prevent the wires between the inverters from
> getting optimized away
>
> (* keep = "true" *) wire [length-1:0] connect;
>
> Additionally you can use LUT instantion primitives for anot gates as
> shown
>
> generate
> genvar k;
> for (k=0; k<length-1; k=k+1)
> begin : not
> LUT1 #(
> .INIT(2'b01) // Specify LUT Contents
> ) LUT1k (
> .O(connect[k+1]), // LUT general output
> .I0(connect[k]) // LUT input
> );
> end
> endgenerate
>
> ENJOY!

Thank you very much guys! Your help is really appreciated.
Regards,
George

Article: 134145
Subject: Re: Opencores DDR2 SDRAM controller with spartan3e starter board
From: blinkenlights <klaus.rindtorff@googlemail.com>
Date: Sun, 27 Jul 2008 23:19:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks Gabor, I will look for the debug parameter.
Your first question already sent me on the right way I believe. After
looking for the data signals in the simulator output again, I realized
that there might be a pipeline bug in the Opencores code, at least for
the way I use it. It looks like the data is latched one clock too
late, just when the data lines go to tristate again. I have modified
that and I now see it working in the simulation. In the implementation
it does work as well, but only if I single-step through my read
operations. If I run it at full speed, it fails again. Could be some
strange effect from my single-step logic. Anyhow, at least I know that
the write operation works fine.

Article: 134146
Subject: Chipscope Error
From: Zhane <me75@hotmail.com>
Date: Mon, 28 Jul 2008 01:35:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Checking expanded design ...
ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<4>' is driving non-
buffer
   primitives:
     pin D on block U_ila_pro_0/ila_pro_0/i_dq/g_dw/4/u_dq with type
FDP
ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<3>' is driving non-
buffer
   primitives:
     pin D on block U_ila_pro_0/ila_pro_0/i_dq/g_dw/3/u_dq with type
FDP
ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<2>' is driving non-
buffer
   primitives:
     pin D on block U_ila_pro_0/ila_pro_0/i_dq/g_dw/2/u_dq with type
FDP
ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<1>' is driving non-
buffer
   primitives:
     pin D on block U_ila_pro_0/ila_pro_0/i_dq/g_dw/1/u_dq with type
FDP
ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<0>' is driving non-
buffer
   primitives:
     pin D on block U_ila_pro_0/ila_pro_0/i_dq/g_dw/0/u_dq with type
FDP
====================================================================
my sender_BUS is INOUT ports

i've made net connections for my Data Trigger with "sender_BUS' of
base type IOBUF.

I'm not able to compile it now after adding the cdc file.

what can I do?

Article: 134147
Subject: Re: Chipscope Error
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 28 Jul 2008 09:42:30 +0100
Links: << >>  << T >>  << A >>

"Zhane" <me75@hotmail.com> wrote in message 
news:a0d26059-8dae-4527-a877-8f7a29aa391c@p10g2000prf.googlegroups.com...
> Checking expanded design ...
> ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<4>' is driving non-
> buffer
>   primitives:
>
> what can I do?

You can not connect directly to the PADs but instead you should connect to 
the signals on the fabric side of the IBUFs and OBUFs.
HTH., Syms. 



Article: 134148
Subject: Re: Chipscope Error
From: Zhane <me75@hotmail.com>
Date: Mon, 28 Jul 2008 02:36:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 28, 4:42=A0pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "Zhane" <m...@hotmail.com> wrote in message
>
> news:a0d26059-8dae-4527-a877-8f7a29aa391c@p10g2000prf.googlegroups.com...
>
> > Checking expanded design ...
> > ERROR:NgdBuild:924 - bidirect pad net 'sender_BUS<4>' is driving non-
> > buffer
> > =A0 primitives:
>
> > what can I do?
>
> You can not connect directly to the PADs but instead you should connect t=
o
> the signals on the fabric side of the IBUFs and OBUFs.
> HTH., Syms.

???
Sorry I dont know what you mean by "the signals on the fabric side of
the IBUFs and OBUFs"

can explain to me?

Article: 134149
Subject: Re: SD Card Controller
From: "RCIngham" <robert.ingham@gmail.com>
Date: Mon, 28 Jul 2008 05:00:37 -0500
Links: << >>  << T >>  << A >>
>
>"John_H" <newsgroup@johnhandwork.com> ha scritto nel messaggio 
>news:MM6dnaCHurSKUhTVnZ2dnUVZ_oPinZ2d@comcast.com...
>> Here's a shot in the dark:
>>
>> Are you certain the clock edge is where you want it relative to the
data 
>> setup and hold time requirements?
>
>The spi driver runs concurrently with the card controller
>logic, in its own state machine. So it has the chance to
>drive clock and data with the right phase according to
>cpol = 0, cpha = 0. Simulation shows a 90 degree
>phase shift between sck and mosi.
>

That is probably not optimal. For *most* SPI interfaces, you want SCK
rising edge in the middle of the MOSI and MISO periods.

UNLESS you have a data sheet that shows otherwise, of course, as there is
no such thing as "standard SPI"!




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search