Clock Edge notation

"rickman" <gnuarm@gmail.com> wrote in message
news:f3419e72-2cf2-4a01-8300-c5184afc38f7@34g2000hsh.googlegroups.com...
On Jul 26, 10:12 am, 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. But like I said, it is not that this is hard to
understand, it is not what I pictured in my mind and so I had to
perform a conversion from the logic to the syntax. That takes time
and is a distraction from making my work accurate.

I have no doubt that others may find that verbose code is easier for
them to read. But I find concise code is best (but not too!
concise). There are any number of different logic forms to be
expressed and each is expressed best in different ways. I think the
selection statement is an operator that has a useful place in VHDL.
I'm just sorry it wasn't included. I guess it would have been hard to
provide for overloading since it does not fit the standard uniary or
binary format.

Rick
So why do you not use schematic capture tools for your designs - or is that
too uncool?

Icky
 
"rickman" <gnuarm@gmail.com> wrote in message
news:6aaeaa92-c512-4f6a-b134-483bd7615592@m36g2000hse.googlegroups.com...
On Jul 26, 12:50 pm, "Icky Thwacket" <i...@it.it> wrote:
"rickman" <gnu...@gmail.com> wrote in message


So why do you not use schematic capture tools for your designs - or is
that
too uncool?

Icky

Is this a serious question? Or are you just playing devil's
advocate?

Probably the single biggest reason to use an HDL instead of schematics
is the portability it provides. Schematics have always locked you
into a manufacturer unless you are willing to reenter your design for
every company's chips you wish to try.

But I was a diehard on schematics. Just like Ray Andraka, I saw a lot
of utility in them. He finally switched when he found that he could
instantiate primitives and achieve the same degree of control over the
design details that he got with schematics. I switched when I found
out how handy it was to have text based designs instead of proprietary
formatted schematics. But there are any number of other reasons. Do
you really not understand what they are? I don't think I ever
considered schematics "uncool". In fact, one of the cooler things
about being an engineer is having an E sized print of a schematic
design hanging on your wall.

Rick
Yep that is a totally serious question.

An HDL gives you portability? - Are YOU serious?

If you are making the best use of the internal FPGA resources an HDL cannot
give you portability, as soon as you instantiate a higher level hardware
function integrated into the device (I am specifically talking DSP/SERDES
type integration here) you are straight away locked into an vendor.

The only way an HDL remains 'portable' is if you work at the primitive
level, something that I certainly am not prepared to do!

Icky
 
rickman <gnuarm@gmail.com> wrote:

On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:
On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley



jonathan.brom...@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.

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) BUT ...
(1) you are limited to the creation of binary operators; so ?: is still
tricky, to put it mildly, and
(2) operator precedence is usually predetermined and deeply embedded in
the parser. The above languages solved this problem by allocating
precisely one precedence level to all operators - in other words, use
brackets.

I suspect extensible operator precedence was the main complexity in
ALGOL-68.

But anyway I suspect you'd have to destroy VHDL to add extensible
operators...

I know I can create a function for this such as select(sel,a,b), but I
like the form of the notation sel ? a : b, very clear and concise. I
guess I could always switch to Verilog... :^)

It may be personal preference, but I find if-then-else MUCH easier to
read in somebody else's code.

?: does save a few of those precious characters though.

- Brian

The problem is not so much reading the code, but is writing. I think
in the terms of the logic, usually a schematic/block diagram. Then I
try to express that logic in the language. It is not uncommon that it
is simply impossible to express the logic in the form I have drawn
it. Then I have to convolute it to come up with something that is
what I have drawn, or at least I hope so.
I don't think drawing logic is a good way to start. Using flow charts
usually leads to more simple solutions because it is easier for a
human to optimize a flow chart than a bunch of logic symbols.

Example: A data mux controlled by the output of an AND of a signal and
the output of a mux. This is four control signals gated together to
drive the control on the data mux. Here is what I ended up with.

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 construction wouldn't be very clear for people that are
relatively new to a programming language. I'd try to avoid it.

How about:

process ( BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
if (BETRSel and Genen)='0' then
BERTEn <= not SyncPOSSel
else
BERTEn <= not GenPOSSel;
end if;
end process;

The code above makes perfectly clear what you are doing. Besides, I
doubt your examples are describing the same logic.

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 see your point and I agree. I would like to write my programmable
logic in C as well. Neither VHDL or Verilog are easy to use.

Yet, you could run your VHDL code through a C pre-processor. This
would allow macro substitution.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
 
"HARRIS VALERIE" <ValHarrisMV@gmail.com> wrote in message
news:774a5490-9f12-4a2e-841a-4f146ae42eca@t54g2000hsg.googlegroups.com...
Here's my issue:

This is the port definition in Verilog:

FSM2 F2(.CLock(fsm2clk),
.reset(fsm2rst),
.Control(ctrl),
.Y(Fsm2Out));

This is the port definition for VHDL:

entity FSM2 is
port (CLock, reset: in std_logic;
Control: in std_logic;
Y: out integer range 0 to 4 );
end FSM2;
Try removing the range from your Y output. You might also want to try
Modelsim 6.4 which has a number of mixed language enhancements.

Hans
www.ht-lab.com




When we run this, the model tech simulator says:

# ** Fatal: (vsim-3362) The type of VHDL port 'y' is invalid for
Verilog connection (4th connection).
# Time: 0 ns Iteration: 0 Instance: /top/FSM2 File: fsm2.vhd
Line: 7
# FATAL ERROR while loading design
# Error loading design
Error loading design

Does anybody know what's wrong with this?

What should I do to connect VHDL ports to Verilog?

Thanks

Valerie
 
"Torsten Landschoff" <t.landschoff@gmx.de> wrote in message
news:6108bb5c-fb02-4aff-8a33-67cf9984dd86@34g2000hsf.googlegroups.com...
On 28 Jul., 15:32, Mike Treseler <mtrese...@gmail.com> wrote:
Torsten Landschoff wrote:
How about the inverse problem (data arriving before the clock because
the clock is forwarded using concurrent signal assignments)?

A clock does not belong in a signal assignment.

-- Mike Treseler

So how does one generate the clock signal in a VHDL testbench?
From what I remember it used to be the case that a concurrent clock
assigment as in :

clock <= not clock after xx;

simulated faster than using a process, however, with all the modern
optimisation techniques I suspect this is no longer the case.

Hans
www.ht-lab.com
 
"Enes Erdin" <eneserdin@gmail.com> wrote in message
news:85ace785-eff5-4f7d-ab5c-75807ff085e3@25g2000hsx.googlegroups.com...
Hi,

I am trying to simulate my design via ModelSim but my design will use
an external RAM in real environment and I could not manage to
instantiate a model for ram. The actual ram has 19 bits of address bus
and 36 bits of data bus. It is a ZBT ram.

What I tried was creating an signal array of 2^19x36 in the testbench
assuming it as an external ram and use it, however this time "out of
memory" error comes out and my simulation crashes.
For such a large memory model you might need to use a sparse array which
AFAIK is only supported in Verilog. If you have access to a dual language
license then it is very simple to add this.

Hans
www.ht-lab.com


Thank in advance for your suggestions.

Regards.

Enes
 
Yannick wrote:
Hi,

I need help for timing constraints in Xilinx virtex 4 Fx.

I have this design with two clocks on bufgmux and two components.

First clock : 50 Mhz
Second clock : 300 Mhz

Component A, need to work at 50Mhz
Component B, need to work at 300 Mhz

___________
| |
| |
|Component|
__________| A |
| | |
| |_________|
|
|\ |
CLK_50M ---| \ |
| \_________|
| / |
CLK_300M---| / |
|/ |
| ___________
| | |
|________| |
|Component|
| B |
|_________|

When I define both clock timing constraints on ucf file, ISE apply 300
Mhz for component A and B.
But the component A doesn't work at 300 Mhz and I don't whant that the
component A work at this frequency.

How i do for put the good frequency on each component whithout use two
bufg instead one bufgmux? (specific timing constraint)

Regards,

Yannick

Yannick,

1) You're posting on the wrong newsgroup. Next time try comp.arch.fpga .
2) You need to RTFM. Specifically, the contraints guide.
3) In the UCF do this:-

INST "component_a_name*" TNM="component_a_bits";
TIMESPEC TS1 = FROM : component_a_bits : TO : component_a_bits : 50ns;

INST "component_b_name*" TNM="component_b_bits";
TIMESPEC TS2 = FROM : component_b_bits : TO : component_b_bits : 50ns;

HTH, Syms.
 
I meant :-
TIMESPEC TS2 = FROM : component_b_bits : TO : component_b_bits : 3.3ns;
 
"Andy Peters" <google@latke.net> wrote in message
news:085f445c-2286-47c4-9d23-fe4f0968684b@a2g2000prm.googlegroups.com...
Here's a weird one. I have a boolean generic, say FOO, that is
determines how some logic is generated. When analyzing with ModelSim
XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
have multiple sources."
The key words here are 'may'...and that it's a 'warning'. Good to question
and peruse all warnings as you're doing, but they will not prevent you from
simulating.

I've done this sort of thing before, although with std_logic and not
natural. So obviously bar (of type natural) is not a resolved type
whereas std_logic is, which is why I've never seen this warning
before.



Is there a better way to do this?
bar <= sel(FOO, bletch, loadthis);

where 'sel' is a function (that you write) that takes three operators, the
first being some form of 'condition' that selects the second argument or the
third argument. After writing this once for the data types you have, you'll
probably see that providing additional function overrides to handle all of
the usual data types for the second and third arguments (std_logic,
std_logic_vector, real, time, etc.) is also useful...as is being able to use
either a boolean or std_logic type for the first argument.

No errors, no warnings.

KJ
 
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:n0n4941trp10iib4lfmcbsfgoc2euraa3e@4ax.com...
On Thu, 31 Jul 2008 14:45:27 -0700 (PDT), Andy Peters <google@latke.net
wrote:

This constant can be used to generate different behaviour in synthesis
and simulation.

Which is not usually a good idea; though there are occasionally good and
safe uses for it. (For example, to greatly speed up a serial interface
to reduce wasted simulation time,
I usually use simply it to surround...
- Code that writes to files during simulation for logging purposes during
debug.
- To add signals that are not intended to be synthesized which are of type
'real' to make working with designs that use the fixed point package easier
to debug.

In either case, I'm not creating different functional behaviour, just adding
additional debug capability.

KJ
 
"XSterna" <XSterna@gmail.com> wrote in message
news:8d123d3e-ac86-45d0-86be-8e31918f261b@m44g2000hsc.googlegroups.com...
Hi,

I am having a quite strange problem when I am using the addition with
std_logic types.
Off to a bad start....std_logic_vectors and addition...oh well.

I am basically using a std_logic_vector containing the address for
accessing a SRAM. After writing an octect in the RAM I am adding 8 to
the address for the next word.
OK.

As I did not have the expecting design, I have displayed the content
of the address vector and I have something ... strange.
Displayed on what?
- Real hardware (possibly hardware issues or timing issues)
- Simulation (none of that nastiness).

Here are the values I obtain :

0000 0000
1100 1000
1001 0000
0101 1000
0010 0000
1110 1000
1011 0000
0111 1000
0100 0000
0000 1000
1101 0000
etc

I can see something is quite correct with the 2^0 -> 2^5 bits but only
for a few time and the 2^6 & 2^7 bits are totally wrong.
A simulation would likely clear this all up...

I thought that it could come from the library I used
Yes, suspect everything else first...then question your own code and design.

but after
different tests it does not seem to be the problem.
Frequently that is the result...library is fine, so it must be the new and
untested, unvalidated design...go figure.

When I try for
exemple a LED_out <= "0000 0000" + 8; everything is correct ...

Here is the reduced portion of the concerning code. I have removed
some signals which does not concern the address mechanism.

------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_arith.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
Use ieee.numeric_std instead of std_logic_arith and std_logic_unsigned.
This isn't the cause of your problem, but numeric_std is an actual standard,
the others are not.

entity RAM_controller is
port (CLK, Reset,flag_data_in: in std_logic;
data_in : in std_logic_vector(7 downto 0);
data_out : out std_logic_vector(7 downto 0);

signal_on : in std_logic; -- 0 : mode transfert - 1 : mode signal
rw : in std_logic; -- 0 : ecriture - 1 : lecture

sram_io : inout std_logic_vector(15 downto 0);
sram_a : out std_logic_vector(17 downto 0);
LED_out : out std_logic_vector(7 downto 0);
);
end RAM_controller;
I wonder where the read and write signals are? Oh well, you're only
interested in the address so far.

architecture arch_RAM_controller OF RAM_controller IS
type state_machine is(idle,RAM_read);
signal current_state, next_state : state_machine;
signal I : std_logic_vector(15 downto 0);
signal counter_write,counter_read : unsigned(7 downto 0);
signal counter_write_next,counter_read_next : unsigned(7 downto 0);
signal addr, addr_next : std_logic_vector(17 downto 0);
begin

process(CLK,Reset)
begin
if Reset='1' then
current_state<=idle;
counter_write <= (others => '0');
counter_read <= (others => '0');
count <= (others => '0');
addr <= (others => '0');
elsif (CLK'event and CLK='1') then
current_state<=next_state;
counter_read <= counter_read_next;
counter_write <= counter_write_next;
count <= count_next;
addr <= addr_next;
end if;
end process;
Synchronous process, so far so good.

process(current_state,rw,flag_data_in,data_in)
begin
counter_read_next <= counter_read;
counter_write_next <= counter_write;
addr_next <= addr;

case current_state is

when idle=
LED_out <= addr;
if rw = '0' then -- write
if flag_data_in = '1' then
next_state <= RAM_write;
else
next_state <= idle;
end if;
else
next_state <= idle;
end if;

when RAM_write=>--ecriture
LED_out <= addr;
sram_a <= addr;
sram_io <= "00000000" & data_in;
sram_we <= '0';
addr_next <= addr + 8;
counter_write_next <= counter_write + 1;
next_state <= idle;

end case;
end process;
Hmmm...you seem to be missing quite a few signals from the sensitivity list.
Quick perusal I see that 'counter_read', 'counter_write', 'addr',
'RAM_write' seem to be missing. This will create a difference between
simulation (if you did this) and synthesis. Synthesis should produce a
warning message to the effect that you have an incomplete sensitivity list
and list all of the above signals and say that it will be assuming that the
others should be added....sounds good, but like I said difference between
sim and actual very bad.

Options:
1. Add the signals and re-simulate
2. Get rid of the two processes and condense it into a single one and
retest. Splitting into a combinatorial process and a separate synchronous
process serves no purpose and creates problems such as:
- The incomplete sensitivity list which creates differences between real
world and simulation.
- Possible creation of latches if there is a signal that doesn't get
assigned for every path through I don't see any instances of this in your
posted code, but you also stripped it down for the posting so who knows.

end arch_RAM_controller;


---------------------------------------------
The flag_data_in is high when a word is transfered by a RS232 link
(the STOP state of the RS232 controller).

If anyone has an idea on this problem it would be great because I am
really clueless on that issue !
Is the input signal 'rw' synchronous to the clk? More generally any input
to the entity most likely needs to be synchronous to clk, but 'rw' is
definitely being used in a way that would require it to be synchronous to
clk.

Have you simulated this?

Timing analysis completed successfully?

KJ
 
XSterna wrote:
If anyone has an idea on this problem it would be great because I am
really clueless on that issue !

Xavier
http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf
 
"XSterna" <XSterna@gmail.com> wrote in message
news:3261eb4c-49a4-4cea-8fde-a8baf08f2d51@r66g2000hsg.googlegroups.com...

Now, the main point I did not really understand is the "all-in-one"
process one. I understand the synchronous and asynchronous scheme in
what you wrote. But in my case I don't really catch how to implement
it.
Below is a snippet of your current code with two processes

process(current_state,rw,flag_data_in,data_in,counter_write,counter_read,addr)
begin
if rw = '0' then -- write
if flag_data_in = '1' then
next_state <= RAM_write;
else
next_state <= idle;
end if;
elsif rw = '1' then
addr_next <= (others => '0');
next_state <= RAM_read;
else
next_state <= idle;
end if;
end process;

process(CLK,Reset)
begin
if Reset='1' then
current_state<=idle;
counter_write <= (others => '0');
counter_read <= (others => '0');
addr <= (others => '0');
elsif (CLK'event and CLK='1') then
current_state<=next_state;
counter_read <= counter_read_next;
counter_write <= counter_write_next;
addr <= addr_next;
end if;
end process;

Next is functionally the same code with one clocked process

process(CLK,Reset)
begin
if Reset='1' then
current_state<=idle;
counter_write <= (others => '0');
counter_read <= (others => '0');
addr <= (others => '0');
elsif (CLK'event and CLK='1') then
if rw = '0' then -- write
if flag_data_in = '1' then
current_state <= RAM_write; -- No need for 'next_state'
else
current_state <= idle;
end if;
elsif rw = '1' then
addr <= (others => '0'); -- No need for 'addr_next' either
current_state <= RAM_read;
else
current_state <= idle;
end if;
end if;
end process;

Basically, all of your *_next signals are not needed, you update the signals
directly. This is just a snip of your code, but should give you the basic
idea.

Except for possible typing errors on my part, both will synthesize to the
exact same thing. The single clocked process has three advantages over the
two process approach:
- Less typing (therefore less room for error)
- Very small chance of getting the sensitivity list wrong which leads to
synthesized results being functionally different than simulation.
- No chance of creating a latch.

KJ
 
rickman wrote:
One suggestion. When implementing counters, it is slightly more
efficient to implement them as loadable down counters.


This is because in most technologies there is a carry chain built in
that can detect when counter is 0. If you are counting up to (M-1)
the synthesizer has to use LUTs to detect the final state if M is not
a power of 2.

Rick
Good point, but remember up counters are fine too! E.g. divide by 200...

if count = 255 then
count <= 56;
else
count <= count + 1;
end if;

Or something like that.


HTH, Syms.
 
"jacko" <jackokring@gmail.com> wrote in message
news:8837cbe8-b3fd-4a25-9cc6-a474556616c5@v57g2000hse.googlegroups.com...
The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.
Post some example so we don't have to guess endlessly about what you're
talking about when you toss around things like
* 'intermediate' signals (as opposed to what? an 'immediate' signal? There
is no such distinction, so why are you making one?)
* latched contents have no relevance....does that mean you write
non-relevant code? Maybe you shouldn't do that

Is it because only some paths through the process do not assign to
them? As I thought this was only relevant to synchronous behaviour.
One can only speculate based on your cloudy description.

You will get a latch any time that you have a possible path through your
logic that does not assign to each and every output of that process...end of
story...simple example

The following example will not produce a latch.

No_Latch : process(abc)
begin
a <= '0';
if (abc = '1') then
a<= '1';
end if
end process No_Latch;

The following example will produce a latch.

Yes_Latch : process(abc)
begin
-- a <= '0';
if (abc = '1') then
a<= '1';
end if
end process Yes_Latch;

Post some useful code and results with a specific question next time.

KJ
 
"jacko" <jackokring@gmail.com> wrote in message
news:9aaec06e-9ac0-4228-8474-fc95cb6380d7@d77g2000hsb.googlegroups.com...
On 9 Aug, 16:24, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:8837cbe8-b3fd-4a25-9cc6-a474556616c5@v57g2000hse.googlegroups.com...



The bit I don't get yet is why a coinational process, with just one
register in the sensitivity list (IR) process is instruction decode
from insrtuction register, inferes latches on intermediate signals,
when there latched contents have no relevance. The intermediates
should always be recalculated.

Post some example so we don't have to guess endlessly about what you're
talking about when you toss around things like
* 'intermediate' signals (as opposed to what? an 'immediate' signal? There
is no such distinction, so why are you making one?)
* latched contents have no relevance....does that mean you write
non-relevant code? Maybe you shouldn't do that
a<=b;
c<=d;
e<=a*c;

--a and c are intrmediate calculations.

To you maybe, to

Well you stated that the instruction register is the only thing in the
sensitivity list is the instruction register so I assume that your code then
is of the form below (where I'll assume that 'a' is the instruction
register)

process(a)
begin
a<=b;
c<=d;
e<=a*c;
end process;

In this case, you should get warnings about an incomplete sensitivity list.
Ignore them if you like living on the edge, but if you do then your
simulation will not match what gets synthesized because the synthesizer will
implement it *as if* you had

process(a,b,c,d)

But simulation will only cause this process to trigger when 'a' changes,
changes on the others won't. I don't know which way you intend it to work,
but the issue is that you'll simulate one set of logic and will synthesize
something completely different so this is a warning that you should fix.

You won't get warnings about latches from the above code, so if you want
some help on that topic, you'll have to post some code demonstrating what
code Quartus is actually flagging...I'm too lazy to download your code from
the web site, run it through Quartus, etc.

KJ
 
"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:6g62f4FehhijU1@mid.individual.net...
jacko wrote:

It *is* a problem because fpga latches are only safe
if excruciating timing constraints are applied in synthesis.
I'll strongly second Mike's advice and I'd go further and state that latches
are never safe unless
- The device actually has a hardware latch as a resource (unlikely
now-a-daze)
- The synthesized code ends up mapping the source code to the above
mentioned latch
- The latch enable signal is sourced from a flip flop.

I doubt that even excruciating timing constraints would get you a reliable
latch because to implement a latch you need, besides timing, a way to
implement redundant logic terms that doesn't get optimized away. You can do
that with non-portable synthesis attributes but there is absolutely no good
reason why you should.

KJ
 
"jacko" <jackokring@gmail.com> wrote in message
news:197cc6f7-1511-428b-96d5-69918c1857bc@l42g2000hsc.googlegroups.com...
Hi

I have optimized alu some. and fixed correct return address stacked.
It is now compiling at 301 LEs, but has a low fmax of 25MHz in C3
speed MAX II. Is there any way of forcing carry routing via VHDL or is
that a tool option?
What makes you think that 'carry routing' is not being done properly? If
you're only getting 25 MHz you've likely written code that is simply not
following a synchronous design process. Either that or you've got a 100 bit
adder or something else unusual.

Take a look at the critical timing path and try to understand what is really
the bottleneck.

KJ
 
"KJ" <kkjennings@sbcglobal.net> wrote in message
news:6lmnk.32983$co7.4027@nlpi066.nbdc.sbc.com...
"jacko" <jackokring@gmail.com> wrote in message
news:9aaec06e-9ac0-4228-8474-fc95cb6380d7@d77g2000hsb.googlegroups.com...
On 9 Aug, 16:24, "KJ" <kkjenni...@sbcglobal.net> wrote:
"jacko" <jackokr...@gmail.com> wrote in message

news:8837cbe8-b3fd-4a25-9cc6-a474556616c5@v57g2000hse.googlegroups.com...



You won't get warnings about latches from the above code, so if you want
some help on that topic, you'll have to post some code demonstrating what
code Quartus is actually flagging...I'm too lazy to download your code
from the web site, run it through Quartus, etc.
Actually, I take that back you can get latches from the code...again, like I
said with the first post, put a snip of your real code and the real warning
about which signal(s) are becoming latches....it's rather pointless to be
guessing about what the problem is with your code when you don't put up a
complete snippet of the problem.

KJ
 
"jacko" <jackokring@gmail.com> wrote in message
news:9aac6166-78db-45b7-9220-dffaa0570f4d@r66g2000hsg.googlegroups.com...
On 9 Aug, 21:09, "KJ" <kkjenni...@sbcglobal.net> wrote:
"KJ" <kkjenni...@sbcglobal.net> wrote in message

news:6lmnk.32983$co7.4027@nlpi066.nbdc.sbc.com...


Now themain thing is as i implemented the alu by explicit xor and and,
I am wondering how o indicate to the synthesizer that a signal should
be fed through fast carry logic.
Synthesis implements the source code that you wrote. If you write stuff
where some 'fast carry logic' can be used it will be, if not, it can't.
Writing your source code as you've done using explicit 'xor' and 'and' will
probably never end up using anything fancy. By writing it in that fashion,
you're doing most of the synthesis work of going from a 'high level'
description into a 'low level' description. By doing this you've likely cut
yourself out of any good tricks that synthesis tools could have done for you
with a more reasonable description. Given a collection of 'xor' and 'and'
equations, just what do you think even could be done with carry logic?

the synth has distributed the alu all
over. knoking fmax to 25MHzor lower.
Synthesis mostly puts things where they are needed in order to communicate
with whatever it is that feeds them. People get it in their head that
something 'should be' all together and mostly they're wrong....they
completely neglect the fact that that something needs to gets its input from
something and the result need to go somewhere else, no logic is an
island...islands get optimized away because no device outputs depend on
their results.

Any idea how to indicate special carry property in vhdl?

By using arithmetic operators and letting synthesis do some of the work and
stop thinking you can do better.

KJ
 

Welcome to EDABoard.com

Sponsor

Back
Top