need a cheap student edition FPGA

<info2@rayed.de> wrote in message
news:94bfff2e-4928-48de-97fb-e622abab0cd1@j22g2000hsf.googlegroups.com...
How are the experiences of others with tools claiming to support SV?
Modelsim-PE
PE ... has basically the same language-parser as the much more
expensive Modelsim-SE, minus the 'advanced verificaton/testbench' features.

The best thing is, Xilinx's OEM version (XE 6.3c) is a great, free way to
practice Systemverilog synthesis-constructs. Ironically, Xilinx ISE/webpack
doesn't support systemverilog yet. (Altera Quartus-II does!)
I'm hoping the next release of ISE/Webpack (11.x?) comes with XE 6.3h or
later -- that'll let me practice OVM 2.0

Synopsys VCS used to be the premier simulator for Systemverilog. Now that
Cadence has finally stopped dragging their feet, and partnered with Mentor
to
offer a competing "de-facto" verification environment (OVM), I'd say Cadence
IUS
is *finally* usable for Systemverilog simulation.

Cadence IUS81
This is the only commercial simulator I have regular access to.
As of 8.1, it's still missing a ton of little things the competition
handles --
let's see, unions, constant-expressions in enum-declarations (must be
'literal'
constants), etc. Nothing major, but all these small annoyances add up.
For example, using the $cast(dest_var, source_var) operator on an enum
ALWAYS fails. Here's an example:
if ( ! $cast( my_enum, my_int) )
$display( "ERROR, can't cast %0d to my_enum!", my_int );
else
$display( "my_int -> my_enum = '%s'", my_enum.name() );

The same code runs fine in Modelsim PE 6.2 (and Questasim/SE, I assume.)

Aldec Active-HDL 7.3sp1 -
I only tried to web-evaluation, but it's far behind Modelsim-PE. It
doesn't even
support package/endpackage, which renders it unusable for any kind of
shared-code organization. (Why would you leave such a critiical language
feature
out for this long?!?) I have high hopes, though. Earlier this year, Aldec
announced future (planned) support for OVM -- so at least Aldec's
flagship, Riviera Pro, is due for more overhauling.

Altera Quartus-II 8.0sp1:
I'm impressed with the level of systemverilog-support...outstanding for a
free tool! Some limitations but very usable for smaller projects. Too bad
Altera's Modelsim (AE 6.1g) is so old, it's not usable for Systemverilog
design.

Synopsys Design Compiler:
Well, definitely the gold-standard in Systemverilog synthesis. (I'd like
to know
how Cadence's RTL Compiler compares.) In terms of comprehensive
Systemverilog
support, Synopsys has it all from top to bottom (synthesis, simulation, LEC,
LINT, etc.)
 
sharp@cadence.com> wrote in message
news:36dc98f7-96f9-4132-aa70-72bf3d94cb51@u6g2000prc.googlegroups.com...
On Jul 24, 6:11 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
Does anybody know how to save the result of the ncverilog preprocessor
to a single file? Thanks in advance.

NC-Verilog does not use a separate preprocessor or preprocessor pass.
Things like macros and `includes are handled by the parser as they are
encountered.
I don't suppose there are plans to add this functionality to irun 8.2?

Some of the OVM-macros are so complicated, it's very hard for a
human to visualize the macro-scattered code without being to
see the preprocessor's output.

At the moment, we're using Novas verdi-2008 to get around this.
As long as the code compiles successfully, Verdi-2008's GUI source-browser
paints the macro-substitited text side-by-side with the original text.

(IUS81's source-browser only does a 'first-level' substitution. It
doesn't auto-recurse nested macros, so it's very limited in usefulness.)
 
<info2@rayed.de> wrote in message
news:94bfff2e-4928-48de-97fb-e622abab0cd1@j22g2000hsf.googlegroups.com...
How are the experiences of others with tools claiming to support SV?
Modelsim-PE
PE ... has basically the same language-parser as the much more
expensive Modelsim-SE, minus the 'advanced verificaton/testbench' features.

The best thing is, Xilinx's OEM version (XE 6.3c) is a great, free way to
practice Systemverilog synthesis-constructs. Ironically, Xilinx ISE/webpack
doesn't support systemverilog yet. (Altera Quartus-II does!)
I'm hoping the next release of ISE/Webpack (11.x?) comes with XE 6.3h or
later -- that'll let me practice OVM 2.0

Synopsys VCS used to be the premier simulator for Systemverilog. Now that
Cadence has finally stopped dragging their feet, and partnered with Mentor
to
offer a competing "de-facto" verification environment (OVM), I'd say Cadence
IUS
is *finally* usable for Systemverilog simulation.

Cadence IUS81
This is the only commercial simulator I have regular access to.
As of 8.1, it's still missing a ton of little things the competition
handles --
let's see, unions, constant-expressions in enum-declarations (must be
'literal'
constants), etc. Nothing major, but all these small annoyances add up.
For example, using the $cast(dest_var, source_var) operator on an enum
ALWAYS fails. Here's an example:
if ( ! $cast( my_enum, my_int) )
$display( "ERROR, can't cast %0d to my_enum!", my_int );
else
$display( "my_int -> my_enum = '%s'", my_enum.name() );

The same code runs fine in Modelsim PE 6.2 (and Questasim/SE, I assume.)

Aldec Active-HDL 7.3sp1 -
I only tried to web-evaluation, but it's far behind Modelsim-PE. It
doesn't even
support package/endpackage, which renders it unusable for any kind of
shared-code organization. (Why would you leave such a critiical language
feature
out for this long?!?) I have high hopes, though. Earlier this year, Aldec
announced future (planned) support for OVM -- so at least Aldec's
flagship, Riviera Pro, is due for more overhauling.

Altera Quartus-II 8.0sp1:
I'm impressed with the level of systemverilog-support...outstanding for a
free tool! Some limitations but very usable for smaller projects. Too bad
Altera's Modelsim (AE 6.1g) is so old, it's not usable for Systemverilog
design.

Synopsys Design Compiler:
Well, definitely the gold-standard in Systemverilog synthesis. (I'd like
to know
how Cadence's RTL Compiler compares.) In terms of comprehensive
Systemverilog
support, Synopsys has it all from top to bottom (synthesis, simulation, LEC,
LINT, etc.)
 
sharp@cadence.com> wrote in message
news:36dc98f7-96f9-4132-aa70-72bf3d94cb51@u6g2000prc.googlegroups.com...
On Jul 24, 6:11 pm, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
Does anybody know how to save the result of the ncverilog preprocessor
to a single file? Thanks in advance.

NC-Verilog does not use a separate preprocessor or preprocessor pass.
Things like macros and `includes are handled by the parser as they are
encountered.
I don't suppose there are plans to add this functionality to irun 8.2?

Some of the OVM-macros are so complicated, it's very hard for a
human to visualize the macro-scattered code without being to
see the preprocessor's output.

At the moment, we're using Novas verdi-2008 to get around this.
As long as the code compiles successfully, Verdi-2008's GUI source-browser
paints the macro-substitited text side-by-side with the original text.

(IUS81's source-browser only does a 'first-level' substitution. It
doesn't auto-recurse nested macros, so it's very limited in usefulness.)
 
<info2@rayed.de> wrote in message
news:94bfff2e-4928-48de-97fb-e622abab0cd1@j22g2000hsf.googlegroups.com...
How are the experiences of others with tools claiming to support SV?
Modelsim-PE
PE ... has basically the same language-parser as the much more
expensive Modelsim-SE, minus the 'advanced verificaton/testbench' features.

The best thing is, Xilinx's OEM version (XE 6.3c) is a great, free way to
practice Systemverilog synthesis-constructs. Ironically, Xilinx ISE/webpack
doesn't support systemverilog yet. (Altera Quartus-II does!)
I'm hoping the next release of ISE/Webpack (11.x?) comes with XE 6.3h or
later -- that'll let me practice OVM 2.0

Synopsys VCS used to be the premier simulator for Systemverilog. Now that
Cadence has finally stopped dragging their feet, and partnered with Mentor
to
offer a competing "de-facto" verification environment (OVM), I'd say Cadence
IUS
is *finally* usable for Systemverilog simulation.

Cadence IUS81
This is the only commercial simulator I have regular access to.
As of 8.1, it's still missing a ton of little things the competition
handles --
let's see, unions, constant-expressions in enum-declarations (must be
'literal'
constants), etc. Nothing major, but all these small annoyances add up.
For example, using the $cast(dest_var, source_var) operator on an enum
ALWAYS fails. Here's an example:
if ( ! $cast( my_enum, my_int) )
$display( "ERROR, can't cast %0d to my_enum!", my_int );
else
$display( "my_int -> my_enum = '%s'", my_enum.name() );

The same code runs fine in Modelsim PE 6.2 (and Questasim/SE, I assume.)

Aldec Active-HDL 7.3sp1 -
I only tried to web-evaluation, but it's far behind Modelsim-PE. It
doesn't even
support package/endpackage, which renders it unusable for any kind of
shared-code organization. (Why would you leave such a critiical language
feature
out for this long?!?) I have high hopes, though. Earlier this year, Aldec
announced future (planned) support for OVM -- so at least Aldec's
flagship, Riviera Pro, is due for more overhauling.

Altera Quartus-II 8.0sp1:
I'm impressed with the level of systemverilog-support...outstanding for a
free tool! Some limitations but very usable for smaller projects. Too bad
Altera's Modelsim (AE 6.1g) is so old, it's not usable for Systemverilog
design.

Synopsys Design Compiler:
Well, definitely the gold-standard in Systemverilog synthesis. (I'd like
to know
how Cadence's RTL Compiler compares.) In terms of comprehensive
Systemverilog
support, Synopsys has it all from top to bottom (synthesis, simulation, LEC,
LINT, etc.)
 
"Fei Liu" <fei.liu@gmail.com> wrote in message news:gbg77f$133$1@aioe.org...
Hello, I have a problem here I can't seem to fix. I have incoming data on
the serial port, I have a RAM module, I'd like to store the incoming data
into RAM. Ram module has an address pin (addr), serial module has data and
data_ready (single clock pulse) pin. I have a bytecount register to keep
track of the address. Here is a code snippet:

always @(posedge clk) begin
if(state == s_recv && data_ready) begin
addr = bytecount;
bytecount = bytecount + 1;
end
end

Here is my problem, I sent over "abcdefg", when I read back, I get
"bbcdefg"; if I sent over "hijklmn" I get back "iijklmn".

I know there is racing issue with my 2 statements in the above code
snippet, I can't seem to find a better way to handle this. Note that I
would potentially use the module to receive data from a higher speed
interface so a simple delay+bytecount_inc is not an optimal solution here.

What's the correct way to handle this situation? Thanks,

Fei
Try replacing = with <=
 
"y_p_w" <y_p_w@hotmail.com> wrote in message
news:591da479.0306230937.42883d68@posting.google.com...
Hi-

I'm currently in the process of creating a synthesizable Verilog
F/S I2C slave, but have little experience with I2C in the real
world.

I'm reading the specs, and I feel I'm getting a pretty good
understanding. If I'm getting this right, the SDA line will only
change when the SCL line is low - except when the master is
indicating a START or STOP command.

So the question I have for those who have really done this is -
in the real world, could a master (or series of masters) issue
a STOP command followed by a START command - all on the same
SCL high period. The latest I2C spec doesn't explain whether
or not this could happen.

This is key to me, since I'm trying to create an I2C slave that
runs solely off the SDA and SCL signals. Whether or not I have
to deal with START and STOP on the same SCL high period will
impact the design choice I make.
AFAIK, that's normal when the bus is idle in the meantime.

The idle bus has all drivers loose and both lines up. When the master ends a
transmission, the last thing is the STOP condition: SCL up, then SDA up.
When the next transmission starts, the first thing is the START condition:
SCL still up, SDA down.

HTH

Tauno Voipio
tauno voipio @ iki fi
 
y_p_w@hotmail.com (y_p_w) writes:

So the question I have for those who have really done this is -
in the real world, could a master (or series of masters) issue
a STOP command followed by a START command - all on the same
SCL high period. The latest I2C spec doesn't explain whether
or not this could happen.
Anything can happen. Please consider combinations of fast CPUs and
sudden power-loss or reset in _all_ phases of the protocol. Remember
for example the "I2C Edge Conditions" problem.


Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
I have often regretted my speech, never my silence.
 
Tauno Voipio wrote:
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EF744FB.AF2FB36E@yahoo.com...
Tauno Voipio wrote:

"y_p_w" <y_p_w@hotmail.com> wrote in message
news:591da479.0306230937.42883d68@posting.google.com...
Hi-

I'm currently in the process of creating a synthesizable Verilog
F/S I2C slave, but have little experience with I2C in the real
world.

I'm reading the specs, and I feel I'm getting a pretty good
understanding. If I'm getting this right, the SDA line will only
change when the SCL line is low - except when the master is
indicating a START or STOP command.

So the question I have for those who have really done this is -
in the real world, could a master (or series of masters) issue
a STOP command followed by a START command - all on the same
SCL high period. The latest I2C spec doesn't explain whether
or not this could happen.

This is key to me, since I'm trying to create an I2C slave that
runs solely off the SDA and SCL signals. Whether or not I have
to deal with START and STOP on the same SCL high period will
impact the design choice I make.


AFAIK, that's normal when the bus is idle in the meantime.

The idle bus has all drivers loose and both lines up. When the master
ends a
transmission, the last thing is the STOP condition: SCL up, then SDA up.
When the next transmission starts, the first thing is the START
condition:
SCL still up, SDA down.

I think he means the other way around, a START followed by a STOP with
no clock transitions inbetween. In essence, this would be an "empty"
frame.

I have not worked with I2C before, so I don't know the answer. But I am
interested since I will be making one as well.

I have not checked opencores.org, but it seems likely that they would
have a core for this. It might be a bit larger than you would want to
use however.


An empty frame is expressely forbidden in the specs. However, the logic must
still not hang up if such a condition should happen.

Tauno Voipio
tauno voipio @ iki fi
I guess that is the answer then. The condition should not occur, but if
it does due to a defect in one component, it should not cause a problem
in another component.


To the OP,

How does this change your design? I would think an empty frame would be
handled like one that is not addressed to your device, no?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
"Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE.invalid> wrote in
message news:5LHJa.361$4q6.102@read3.inet.fi...
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EF744FB.AF2FB36E@yahoo.com...
Tauno Voipio wrote:

"y_p_w" <y_p_w@hotmail.com> wrote in message
news:591da479.0306230937.42883d68@posting.google.com...
Hi-

I'm currently in the process of creating a synthesizable Verilog
F/S I2C slave, but have little experience with I2C in the real
world.

I'm reading the specs, and I feel I'm getting a pretty good
understanding. If I'm getting this right, the SDA line will only
change when the SCL line is low - except when the master is
indicating a START or STOP command.

So the question I have for those who have really done this is -
in the real world, could a master (or series of masters) issue
a STOP command followed by a START command - all on the same
SCL high period. The latest I2C spec doesn't explain whether
or not this could happen.

This is key to me, since I'm trying to create an I2C slave that
runs solely off the SDA and SCL signals. Whether or not I have
to deal with START and STOP on the same SCL high period will
impact the design choice I make.


AFAIK, that's normal when the bus is idle in the meantime.

The idle bus has all drivers loose and both lines up. When the master
ends a
transmission, the last thing is the STOP condition: SCL up, then SDA
up.
When the next transmission starts, the first thing is the START
condition:
SCL still up, SDA down.

I think he means the other way around, a START followed by a STOP with
no clock transitions inbetween. In essence, this would be an "empty"
frame.

I have not worked with I2C before, so I don't know the answer. But I am
interested since I will be making one as well.

I have not checked opencores.org, but it seems likely that they would
have a core for this. It might be a bit larger than you would want to
use however.


An empty frame is expressely forbidden in the specs. However, the logic
must
still not hang up if such a condition should happen.

Tauno Voipio
tauno voipio @ iki fi


Hi, I have done this with a Lattice 1016 (64 registers)
The start condition, SCL high and SDA falling is to put the device in
lets call it "address compare mode", if the address (Bit 1-7) matches the
device goes
into "read or write mode" depending on bit0 , otherwise the "I'm not
interested mode",
i.e. the "not address compare mode" and "not read read or write mode"

This is determined at the rising edge of the 9th SCL pulse. So the start
condition is
a mode reset command. Note that controllers like the PCF8584 have slow
rising
and falling signals. Your FPGA will be ways too fast for this, so you will
have
to register the signals to determine the transitions.

Example: clock speed 1Mhz (actual speed)
SCL2 = SCL1 = SCL
Not_SCL2 And SCL1 = transitionevent

Tip: in read/write mode where the 9th SCL pulse is used for ACK generation
you can also use the rising edge to generate a read or write pulse to
communicate
with a device. With this you can have a continuous 8-bit data stream into or
from
the device. Ideal for a graphical LCD-display (and whenever there is a
connection
with a high frequency and a low frequency device)

Carel Harmsen
 
"Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE.invalid> wrote in message news:<5LHJa.361$4q6.102@read3.inet.fi>...
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EF744FB.AF2FB36E@yahoo.com...
Tauno Voipio wrote:

"y_p_w" <y_p_w@hotmail.com> wrote in message
news:591da479.0306230937.42883d68@posting.google.com...
Hi-

I'm currently in the process of creating a synthesizable Verilog
F/S I2C slave, but have little experience with I2C in the real
world.

I'm reading the specs, and I feel I'm getting a pretty good
understanding. If I'm getting this right, the SDA line will only
change when the SCL line is low - except when the master is
indicating a START or STOP command.

So the question I have for those who have really done this is -
in the real world, could a master (or series of masters) issue
a STOP command followed by a START command - all on the same
SCL high period. The latest I2C spec doesn't explain whether
or not this could happen.

This is key to me, since I'm trying to create an I2C slave that
runs solely off the SDA and SCL signals. Whether or not I have
to deal with START and STOP on the same SCL high period will
impact the design choice I make.


AFAIK, that's normal when the bus is idle in the meantime.

The idle bus has all drivers loose and both lines up. When the master
ends a
transmission, the last thing is the STOP condition: SCL up, then SDA up.
When the next transmission starts, the first thing is the START
condition:
SCL still up, SDA down.

I think he means the other way around, a START followed by a STOP with
no clock transitions inbetween. In essence, this would be an "empty"
frame.

I have not worked with I2C before, so I don't know the answer. But I am
interested since I will be making one as well.

I have not checked opencores.org, but it seems likely that they would
have a core for this. It might be a bit larger than you would want to
use however.


An empty frame is expressely forbidden in the specs. However, the logic must
still not hang up if such a condition should happen.

Tauno Voipio
tauno voipio @ iki fi

Thanks for the answer. I actually re-read the spec, and noticed
that a STOP following a START in the same SCL high period is illegal.
I'm going to ignore an illegally applied STOP (i.e. illegal STOP
ignored). I was also worried about the possibility of repeated STOP/
START/STOP/START sequences.

However - as a follow-up question, would it be possible to see SCL
toggle after a STOP before the next START command "in the real world"?
None of the timing diagrams in the spec seem to address this
possibility; all diagrams show SDA and SCL staying high for the
foreseeable future. I'd guess that the thing to do is simply put
put the I2C slave in a wait state until a START condition is seen. I
wouldn't see any reason to toggle SCL between a STOP and the next
START, but I haven't seen any real-world designs.

Again - many thanks for the replies.
 
An empty frame is expressly forbidden in the specs. However, the logic
must
still not hang up if such a condition should happen.
I feel it is a bit futile forbidding illegal events because sooner or later
they will happen either through bugs or malfunction.

Personally I would make my I2C slaves enter the idle state whenever they saw
a stop condition (legal or not). Seems a fair and simple way of entering
resetting slave state machines without sending any bytes, even if the spec
forbids it.

If it happens to be an illegal transition then the I2C spec does not oblige
me to do anything in particular, so I can keep my I2C slave logic simple. If
I had to implement things like roll-back after malformed messages, I might
need large n-byte roll-back buffers.
 
Thanks for the answer. I actually re-read the spec, and noticed
that a STOP following a START in the same SCL high period is illegal.
I'm going to ignore an illegally applied STOP (i.e. illegal STOP
ignored). I was also worried about the possibility of repeated STOP/
START/STOP/START sequences.

However - as a follow-up question, would it be possible to see SCL
toggle after a STOP before the next START command "in the real world"?
None of the timing diagrams in the spec seem to address this
possibility; all diagrams show SDA and SCL staying high for the
foreseeable future. I'd guess that the thing to do is simply put
put the I2C slave in a wait state until a START condition is seen. I
wouldn't see any reason to toggle SCL between a STOP and the next
START, but I haven't seen any real-world designs.

Again - many thanks for the replies.
Hi



Well that's what really matters (IHO), "the real world". And in the real
world everything is possible. You can have a lousy implemented
micro-controller software I2C or even if you are debugging the hardware you
can accidentally toggle a line. I know applications where they misuse the
spec and by driving the SCL low between STOP and START for a certain time,
they signal other devices for example busmaster takeover. Everything is
possible.



If you are designing this for a real application you have to deal with the
real world and you must handle all the situations you can think off. It's
very clumsy if your hardware is 'hanging'. Master controllers are build
by spec's and slaves by sense.



Gerard



www.stacktools.com
 
y_p_w wrote:
Well - here's my concerns and thinking:

1) It seems that the preferred method is to have a STOP condition
(SDA rising when SCL=1) on the same SCL high period as a START
period (SDA falling when SCL=1). This would look like this:
_________________________
SCL ___| |_____
_________________
SDA _______| |_________

2) As far as I can tell the spec says nothing about SCL changing
between a STOP and START. I wouldn't see any advantage to it,
but I couldn't sense it was illegal. I would suppose any
clock toggling before a START should just be ignored until a
START is detected.

3) I was worried about whether a master could "change its mind"
after issuing a start if it was suddenly occupied with something
considered more important. Fortunately, this doesn't seem to
be a problem.

4) Most of what I'm planning is a straightforward FSM clocked on
the negedge of SCL. The START and STOP logic I'm planning on
using isn't as straightforward. This was the part that would
have been messed up if I had to account for multiple START or
STOP methods. I wanted to create a START detected signal, and
use that to tell the FSM when to start monitoring SDA.

5) I could possibly use a high-speed internal clock. However -
the goal is a low-power design, and I was told that just
toggling the clock tree would create unnecessary power
consumption.
I have not given this a lot of thought, but I believe you can use two
FFs (with resets) to detect the start/stop conditions and maintain a
state of disabled/enabled.

The start FF is clocked on the falling edge of SDA with SCL on the D
input. This FF will be set on a start condition. The stop FF will be
clocked on the rising edge of SDA with SCL on the D input. This FF will
be set on the stop condition. The start FF being off will hold the stop
FF in reset. The stop FF being set will reset the start FF. So the
sequence will be;

1) both FFs clear
2) on start, the start FF is set and the rest of the circuit is enabled
3) on stop, the stop FF is set which clears the start FF
4) the start FF being cleared also clears the stop FF

The only issue I can see with this design is that the stop FF will
generate a reset pulse determined by the time it takes to reset both FFs
plus the routing. Some people would object to this saying it may
violate the timing requirements of your logic. If so, you may want to
use the LUT or the OR array with the FF to add some extra delay. In
general this should work ok since it is basically self timed logic.

On the other hand, using a synchronous design should not consume much
power. Unless you are going for power below 100 uA, a low power CPLD
(like the coolrunner) should be able to run at 1 MHz (fast enough for
most I2C chips at 400 kb/s) with power at that level.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3EF87139.36651031@yahoo.com...
(-- most clipped, TV --)

I know nothing about the actual details of this protocol, but it
seems to me that something is off the rails. Just the signal
names suggest SerialData and SerialClock. Some edge of SCL must
capture the state of SDA. The above protocol suggests that SDA
can only change while SCL is high, However that conflicts with
the idea that particular transitions on SDA during SCL high are of
special significance, such as message framing.
In actual data transmission it's not allowed to change the data when the
clock is high. The start and stop conditions are distinguished from normal
data bits by breaking the data transfer protocol here.

I seem to vaguely recall that I2C is a collision detection and
backoff system with priority determined by addresses, operating at
baseband.
Yes - the contention is taken care by the open-drain/collector nature of the
bus. The master seeing its output clamped down by another master has to
backoff.

There is a similar method to synchronise the clocks: any station feeling
that the things are going too fast is allowed to extend the clock-down time
by clamping it. The sending station has to honour the clock clamp and wait.

HTH

Tauno Voipio
tauno voipio @ iki fi
 
Opencores and Xilinx have VHDL I2C code that might be of use.
Though of course there is no warranty on its correctness.
 
Multicycle paths are paths between registers that intentionally take more
than one clock cycle to become stable. For example a register may need to
trigger a signal every second or third rising clock edge.

A False path is any path that is not relevant to a circuit's operation.

A good description of both multicycle and false paths can be found in the
following Timing Analysis App Note:

http://www.altera.com/literature/an/an123.pdf

Subroto Datta
Altera Corp.




"LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message
news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de...
Hi,
Can anyone tell me what is Multi Cycle path and False path?

thanks
Lijo
 
There is a short and good example on multi-cycle path. Thanks.
http://www.saros.co.uk/hdlsolutions/appsnotes/leonardo/SAN001.pdf

- Ray

In comp.arch.fpga Subroto Datta <sdatta@altera.com> wrote:
Multicycle paths are paths between registers that intentionally take more
than one clock cycle to become stable. For example a register may need to
trigger a signal every second or third rising clock edge.

A False path is any path that is not relevant to a circuit's operation.

A good description of both multicycle and false paths can be found in the
following Timing Analysis App Note:

http://www.altera.com/literature/an/an123.pdf

Subroto Datta
Altera Corp.



"LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message
news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de...
Hi,
Can anyone tell me what is Multi Cycle path and False path?

thanks
Lijo


--
 
"Subroto Datta" <sdatta@altera.com> wrote in message
news:qXuUa.3036$NV3.1143@newssvr31.news.prodigy.com...
Multicycle paths are paths between registers that intentionally take more
than one clock cycle to become stable. For example a register may need to
trigger a signal every second or third rising clock edge.

A False path is any path that is not relevant to a circuit's operation.

A good description of both multicycle and false paths can be found in the
following Timing Analysis App Note:

http://www.altera.com/literature/an/an123.pdf

Subroto Datta
Altera Corp.
From a conceptual standpoint, these definitions are mostly correct.
But be aware that different CAD-tool vendors (Synopsys, Cadence,
etc.) may treat the *operational* meanings of false-path differently..

In Synopsys's case, their application manuals have clear
examples when to use 'set_disable_timing' versus 'set_false_path.'
The problem with set_false_path is that it can (unintentionally)
affect more than just timing-constraints.

"LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message
news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de...
Hi,
Can anyone tell me what is Multi Cycle path and False path?

thanks
Lijo
 
"hrwieuyriwru" <jkshdfkjhskdjfksfksd@dfuosdf.com> wrote in message news:<WyHVa.696$il2.75461696@newssvr21.news.prodigy.com>...
"Subroto Datta" <sdatta@altera.com> wrote in message
news:qXuUa.3036$NV3.1143@newssvr31.news.prodigy.com...
Multicycle paths are paths between registers that intentionally take more
than one clock cycle to become stable. For example a register may need to
trigger a signal every second or third rising clock edge.

A False path is any path that is not relevant to a circuit's operation.

A good description of both multicycle and false paths can be found in the
following Timing Analysis App Note:

http://www.altera.com/literature/an/an123.pdf

Subroto Datta
Altera Corp.

From a conceptual standpoint, these definitions are mostly correct.
But be aware that different CAD-tool vendors (Synopsys, Cadence,
etc.) may treat the *operational* meanings of false-path differently..

In Synopsys's case, their application manuals have clear
examples when to use 'set_disable_timing' versus 'set_false_path.'
The problem with set_false_path is that it can (unintentionally)
affect more than just timing-constraints.




"LIJO" <lijo_eceNOSPAM@hotmail.com> wrote in message
news:bftlvd$iao78$1@ID-159866.news.uni-berlin.de...
Hi,
Can anyone tell me what is Multi Cycle path and False path?

thanks
Lijo
Here are some examples I can think of.

Lets say you have a mode bit that you use in your logic and you know
some paths specifically do not exist when the core is not in that
mode, that becomes a false path.

Lets say, you do a complex logic such as a CRC and find that your
final CRC evaluation takes more than one clock cycle (based on byte
enables) and cannot meet the speed requirements. You can pipeline the
data and calculate final CRC in multiple clock cycles.

Open to learn more :)
 

Welcome to EDABoard.com

Sponsor

Back
Top