Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You will find one in my floating point packages:Hello folks,
I would like to know how we can implement a tan inverse in VHDL which
shld be also synthesizable.
Well, my std_logic_1164 hasn't got an sll for std_logic_vectors in itHuh? I've been doing std_logic_vector (msb downto lsb) for years and
never had any problems. I don't think there is any "naturalness"
about doing (1 to something). Or have I misunderstood what you are
saying?
What do you think will be result of
key := ((BS(0) and x"01") sll 6) or ((BS(1)srl 2) and x"3F");
where
subtype BYTE is std_logic_vector (7 downto 0);
type TBYTE_STR is array (0 to 6) of BYTE;
variable BS: TBYTE_STR;
key: BYTE;
Check the "and" and "sll" functions in the std_logic_1164 package, they both
return
VARIABLE result : std_logic_vector ( 1 TO l'LENGTH );
Does Verific support the following?The problem with pragma's is that there is no written spec
on how they should work. So if you can, try to avoid them.
No, we don't. Mainly because these are never used by HDL designers.Rob,
The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.
Does Verific support the following?
-- RTL_SYNTHESIS OFF
-- RTL_SYNTHESIS ON
I was involved in the 1076.6 working group, back in the early 90s.I dispute your claim about there being no written spec.
You will find these synthesis directives specified
and standardized in IEEE 1076.6-1999.
In the EDA community we have a major disconnect
between EDA vendors, users, and standards developers.
We need to proactively solve this problem.
The old methodology of a group of experts collectively
developing and publishing a standard is not working.
The problem is that after developing new features, the
features need to be marketed to the user community
and then the user community needs to nag the EDA vendors
to implement the new features.
There is no one party that the blame can be placed on.
Standards developers sometimes do not address users
needs. Users do not have time to nag the EDA vendors.
EDA vendors do not have enough revenue to benevolently
implement features that have little value to the
user community and, hence, their product.
There are changes happening in the EDA standards
community. Recently Accellera was granted rights
by IEEE to make derivative works of the VHDL
standard (IEEE 1076) and has formed a VHDL working
group. While it is still in its early stages its shows
promise of having a model that will ensure that user
prioritized features get standardized. This in turn
will reassure EDA vendors that their product will have
a higher value to their users if they implement the
newly standardized features.
SynthWorks firmly believes in this process and has
become a member of Accellera to support this effort.
I urge experienced VHDL users to participate in this
effort. I suspect that most of the the meaningful
language revisions to VHDL will be done by the
Accellera WG. The VHDL-200X Fast Track work, which
is currently held up by lack of funding, has been
submitted the Accellera WG for their consideration,
prioritization, and funding. Currently funding is
necessary to fund the task of LRM writing.
While non-members of Accellera do not have an official
vote, you do have influence in the form that well
thought out discussions are generally given
consideration. One way to look at it is there are
very few organizations of this type that will turn
away free labor.
Best Regards,
Jim Lewis
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yeah, it's a mess out there.We support pragma's which are used in real life EDA tools :
-- <pragma_trigger> translate_off
-- <pragma_trigger> translate off
pragma_trigger> by default includes the defacto standard vendor names.
This was the template used by all vendors, and there is/was no need to
change that.
You are right.
You're wrong. I develop VHDL code for multiple VHDL compilers from
Xilinx, Synopsys and Synplicity. According to your convention, I
should write:
-- synopsys translate_off
-- xilinx translate_off
-- synplicity translate_off
... my code ...
-- synplicity translate_on
-- xilinx translate_on
-- synopsys translate_on
Frankly I don't see how standardization could help here.If now, I want to compile my VHDL code for Altera and use its Quartus
compiler, I should look for the pragmas in all my VHDL files and add
your --altera translate_off/_on. Honestly, I think that you miss the
point for standardization ;-)
You just invented yet another pragma-trigger : -- RTLIt's funny to know that Synplicity supports the -- SYNOPSYS pragmas
and that Synopsys supports the standardized -- RTL SYNTHESIS_ON/_OFF
ones (as well as the -- SYNOPSYS). In this mess, I would rather
suggest to use:
-- RTL SYNTHESIS_OFF
-- <your vendor @ a point in time> TRANSLATE_OFF
... my code ...
-- <your vendor @ a point in time> TRANSLATE_ON
-- RTL SYNTHESIS_ON
I think it is much easier to follow the de-facto standard :and to put your EDA vendor under high pressure to add the official
standardized pragmas in its VHDL parser. Designers are responsible for
informing them again and again on their needs incl. their need for
standardization.
Eric
That's one external clock cycle, not zero.... NO time because the external module is expecting response on the
next clock cycle.
Any synchronous design will have problems with asynchronousI have read several posts in this newsgroup
explaining that the state machine would have to be very tricky
to handle unregistered inputs.
as a handshake and latch the data on the sameSome additional info:
The clock of the FSM is provided by the external module.
In that case, you can just turn around the data strobe
In a synchronous design, even one with 30,000I have read the following in one post discussing latches:
"None of the above applies to FPGA, you will have no control over
anything and your timing will be horrible so forget it. "
Hi,
I am currently working with the 1727 bit wide shift register....For my
design requirements, I had to change it to a 3454 bit wide shift
register( 2*1727)...
Hi,
I am currently working with the 1727 bit wide shift register....For my
design requirements, I had to change it to a 3454 bit wide shift
register( 2*1727)...
When I did this and implemented the design, I have an error in the
Mapping that:
The design is too large for the device and package (I am using xc3s400
and tq144- spartan3)
So instead I am working on two shift registers, each 1727 bit wide....
and giving the output of one shift reg as input to the other...
This would still use the same number of resources ..so I am getting the
same Mapping error....I tried contacting Xilinx support.....waiting for
some help..
Is there another method to work around this..to minimize the design...
Or I was wondering if I should change the fpga I am using...that would
mean a whole lot of other changes on the board....
But yes that would be last resort type of thing....
Any suggestions or ideas
Thanks,
Methi
bits length. You can either use two address counters, one for the readIs the shift register the only thing in the design?
Nopes I have my design doing a whole lot of things...but its only when
I changed the length of the shift register that I came across the
Mapping error.
Are you using a reset for those shift elements?
I am not using any reset...It takes in a clock...and shifts a bit for
every rising edge of the clock...
Is it serial-in, serial-out?
Yes its serial_in and serial_out
Are there frequency constraints?
No.
Is the shift register fixed in length or variable?
Its a variable shift register....the length is determined by an input
variable called "right".
The code is as follows:
entity shifting_two is
Port ( shiftin : in std_logic;
clock_in : in std_logic;
right : in integer;
shiftout : out std_logic);
end shifting_two;
architecture Behavioral of shifting_two is
signal shift_register : std_logic_vector ( 3454 downto 0 ):= (others =
'0');
begin
process(clock_in)
begin
if rising_edge(clock_in) then
shift_register <= shift_register( 3453 downto 0 ) & shiftin;
shiftout <= shift_register(right-1);
end if;
end process;
end Behavioral;
How can I use a BlockRam...?
For that, you want to use a block RAM, which will give you up to 18K
in it. Something like this should do the trick for you:Hi Ray,
Are you talking about a BRAM core available in Xilinx?
Ive only come across the RAM based shift reg which goes upto 1024 bits
(xilinx 6.3i)
Or Should I be working on a BRAM code in vhdl...
Thanks,
Methi
I was talking about a VHDL module with an instantiated RAMB16 primitive
If you are delaying a single pulse/edge for 3454 ticks,I am just using the output of my shift register...which is the MSB
(this keeps changing depending on the value of the variable
"right")...as input to another component....its a pulse...
a modulo-N count instead of a straight 14 bit binary count. I showedMethi,
Take a BlockRAM, with both ports configured as 16K x 1.
Make one port Write and the other one Read. Clock both ports with your
data clock.
Drive the Write address with a counter that you increment with the data
clock.
Drive the Read address from a subtractor circuit that subtracts the
length N of your shift register from the Write address.
Now you have a programmable-length shift register from the D input of
the write port to the Q output of the Read port.
And you get up to 16K bit length in a single BRAM plus four CLBs (14
bit counter plus 14-bit subtractor).
Peter Alfke
Peter, with SPartan3, he can do it with one port of the BRAM if he uses
Mike, I assumed this was more like a line buffer where he needed tomethi wrote:
I am just using the output of my shift register...which is the MSB
(this keeps changing depending on the value of the variable
"right")...as input to another component....its a pulse...
If you are delaying a single pulse/edge for 3454 ticks,
there are easier ways to do it than with a shift register.
-- Mike Treseler
I understand. And it did not for this pragma, and other 1076.6 'synthesis' features.Rob,
The problem with pragma's is that there is no written spec on how they should work. So if you can, try to avoid them.
Does Verific support the following?
-- RTL_SYNTHESIS OFF
-- RTL_SYNTHESIS ON
No, we don't.
Not surprising as I don't think anyone does.
The point of my question was to illustrate that
the process of standards being made by benevolent
experts does not always work well.
Right.No, we don't. Mainly because these are never used by HDL designers.
Why support something that is not used, and for which there is already
an existing solution ?
This illustrates the classic stand-off:
Vendors: Why implement a new feature if no-one uses it.
Users: Why use a new feature if not all the vendors in
my current design flow implement it.
Without devine intervention, this process will never work.
It's not difficult to implement, but we are not solving a problem here.We support pragma's which are used in real life EDA tools :
-- <pragma_trigger> translate_off
-- <pragma_trigger> translate off
pragma_trigger> by default includes the defacto standard vendor names.
This was the template used by all vendors, and there is/was no need to change that.
You are right.
To be fair, 1076.6 was developed in the time frame between
1996 and 1998 and the only common pragma trigger that
I was aware of was "-- synopsys". I think "-- pragma"
either came out during the same time or a little later.
The WG chose the pragma trigger "RTL_SYNTHESIS".
One reason was to differentiate RTL from behavioral
synthesis. Since VHDL was taking so much abuse about
having long names, rather than translate_off and
translate_on it was shortened to OFF and ON.
Based on your template, the IEEE pragma would adds the
format:
-- <pragma_trigger> off
This does not seem unreasonable or difficult to implement.
We would only need one flavor if all tools supported the
same one.
If you want to persue this for a standards change, then I seriouslyAlso note that if the standard is broken there is
no reason not to fix it.
No, I did not. Since there is no need for this pragma.But even for the RTL_SYNTHESIS OFF pragma, there is no definition of hiw to deal with nesting (and with mixing-in existing
pragma's).
True. Have you submitted a issue report with respect to this?
ISAC is alive and working to make sure all issues get forwarded
to the right place and so they can be worked on.
I would like Accellera to slow down.I was involved in the 1076.6 working group, back in the early 90s.
Since your product is integrated into 35 vendor tools,
you really should be part of the current standards process.
My main point is that we have a new standards organization
called Accellera. They are working hard to create standards
that represent user priorities. Users will want to use
these features. Your wisdom will certainly help us create
something better than we could without you. Furthermore,
if cost is an issue, non-members can participate, they just
can't have an official vote on all items. Note that this
year VHDL has lots of work that needs to get done so anything
you can do to help funding would be greatly appreciated.
Best Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
parser for doxygen?Mike Treseler <mike_treseler@comcast.net> writes:
If the aim were to document the
design, I would do it as comments
in the source and testbench code.
Sounds like what doxygen does for C++ code. Has anyone written a verilog
RegardsI document testcases as comments with a special prefix. These are
then filtered out and processed with LaTeX, giving a nice PDF
file. One could also embed diagrams in description languages like
pstricks, metapost, dot, pic etc. and handle them in the same way.
If somebody has already done this, I'd love to hear about it.
To the original poster: take a look at emacs' vhdl-mode and its
integration into speedbar for a hierarchy parser.
Cheers,
Colin
--
If God had not given us sticky tape, it would have been necessary to
invent it. [Pete Zakel]
No probleme thereshift_register <= shift_register( 3453 downto 0 ) & shiftin;
This alone would probably synthesize to 256 LUTs configured as SLR16.
2k-LUTs to implement it and it will be reaallllyyyy slow.shiftout <= shift_register(right-1);
But this is a 3453 to 1 multiplexer. Without any tricks you need about
Yes, but a single pulse, or many pulses? That was Rays question.I am trying to delay a pulse by N ticks where N takes a maximum value
of 3454...N is a variable here....
You don't need valid in the sensitivity list - but does not solve theHowever, it doesn't get synthesized.
....
30 process (reset, clock, valid)
You know, that the upper and lower bound of data_array1 are connected49 pick2 := data_array1((((x1+1)*w)-1) downto (x1*w)) ...
....
Error: VHDL error at msort_c.vhd(49): left bound of range must be a
constant