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
2017JanFebMarApr2017

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 156725

Article: 156725
Subject: Re: HELP: Edge triggering of mode register, Verilog
From: Bruce Varley
Date: Sun, 08 Jun 2014 20:50:33 +0800
Links: << >>  << T >>  << A >>
On Sun, 08 Jun 2014 06:15:03 -0500, "mnentwig" <24789@embeddedrelated>
wrote:

>Hi,
>
>your approach is typical digital-design textbook but it's completely wrong
>for an FPGA, sorry. 
>It will work for a small example but it doesn't scale.
>
>On FPGAs, use synchronous logic. That means, information and the timing is
>separated. You have information signals and clocks. Edge triggering is done
>on clocks only.
>This matters because clock and information signals are physically separate
>on the FPGA and you cannot use one in place of the other.
>
>The problem is, generic Verilog tutorials, books etc aren't necessarily
>applicable to FPGA, because the language is more capable than the hardware.
>The same for digital design, the FPGA hardware dictates what you can do and
>(mostly) how it should be done.
>
>Here's how it should look instead: The task is to act on opening or closing
>switches - detect a transition of the switch signal. 
>I use a "clk" signal that is available on every FPGA board, let's' say 100
>MHz (or whatever)
>
>input wire switch;
>reg switch_prev = 0;
>wire switchOn = (switch & !switchPrev);
>wire switchOff = (!switch && switchPrev);
>reg pump = 0;
>
>always @(posedge clk) begin
>  if (switchOn) begin pump <= 1; end
>  if (switchOff) begin pump <= 0; end
>end
>
>
>You could read up on "Moore" (and "Mealy") machines as a starting point for
>synchronous logic design. Once I manage to formulate the task as Moore
>machine, an FPGA implementation is only a formality.
>It may seem abstract at first, but it's a straightforward path through the
>digital design "jungle".	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com

>#define MAXSUBST  40
Thanks very much, guys,. Your explanations have helped me understand
the situation much better. 

Article: 156726
Subject: Re: HELP: Edge triggering of mode register, Verilog
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 08 Jun 2014 08:21:19 -0500
Links: << >>  << T >>  << A >>
Hi,

one line was missing:

input wire switch;
reg switchPrev = 0;
wire switchOn = (switch & !switchPrev);
wire switchOff = (!switch && switchPrev);
reg pump = 0;

always @(posedge clk) begin
  switchPrev <= switch;
  if (switchOn) begin pump <= 1; end
  if (switchOff) begin pump <= 0; end
end

What's important to know is that "<=" assignments only becomes effective
after the ongoing clock cycle has completed. The wire "=" assignments in
this example are combinational logic and cause zero delay.  
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156727
Subject: Re: 22V10 programmer
From: Jens Petersen <jp@c.dk>
Date: Sun, 08 Jun 2014 16:25:09 +0200
Links: << >>  << T >>  << A >>
On Sun, 08 Jun 2014 06:14:09 -0600, hamilton <hamilton@nothere.com>
wrote:

>Does anyone know of a cheap 22V10 programmer ?

With G540 I have programmed 22V10, 20V8 and 16V8.

<http://www.ebay.com/itm/New-Genius-G540-USB-Universal-Bios-GAL-Programmer-EPROM-FLASH-51-AVR-PIC-MCU-SPI-/261357384837>
-- 
OV1A Jens

 Hard work has a future pay-off. Laziness pays off now! 

Article: 156728
Subject: Re: 22V10 programmer
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Mon, 09 Jun 2014 03:07:03 +0200
Links: << >>  << T >>  << A >>
On 06/08/2014 02:14 PM, hamilton wrote:
> Does anyone know of a cheap 22V10 programmer ?
>
> or maybe a Atmel ATFxxxx programmer ?

Oh, thank you.
More opportunity to spam:
https://github.com/klammerj/atfprog/tree/master/gal_min

You can probably set this up on a breadboard...




Article: 156729
Subject: Re: Access custom VHDL types in TCL script
From: Robert Schilling <rschilling@student.tugraz.at>
Date: Mon, 9 Jun 2014 10:43:26 +0200
Links: << >>  << T >>  << A >>
> 
> If all else fails you can add a tedious but trivial VHDL wrapper to
> interface between everything-is-an-integer land and a decent type system.

Thank you for your response. This is what I did meanwhile. It works but 
I thought if there other possibilities.

Robert

--
Student of Telematics


Article: 156730
Subject: Re: Access custom VHDL types in TCL script
From: HT-Lab <hans64@htminuslab.com>
Date: Mon, 09 Jun 2014 10:22:23 +0100
Links: << >>  << T >>  << A >>
On 09/06/2014 09:43, Robert Schilling wrote:
>>
>> If all else fails you can add a tedious but trivial VHDL wrapper to
>> interface between everything-is-an-integer land and a decent type system.
>
> Thank you for your response. This is what I did meanwhile. It works but
> I thought if there other possibilities.
>
> Robert
>
> --
> Student of Telematics
>

Not sure what simulator you use but if you use Modelsim you can force 
enumerated types.

signal opc : alu_op_code;

force -freeze /bla/opc ALU_OP_IDLE 0

Good luck,
Hans
www.ht-lab.com

Article: 156731
Subject: Re: 22V10 programmer
From: hamilton <hamilton@nothere.com>
Date: Mon, 09 Jun 2014 08:13:52 -0600
Links: << >>  << T >>  << A >>
On 6/8/2014 7:07 PM, Johann Klammer wrote:
> On 06/08/2014 02:14 PM, hamilton wrote:
>> Does anyone know of a cheap 22V10 programmer ?
>>
>> or maybe a Atmel ATFxxxx programmer ?
>
> Oh, thank you.
> More opportunity to spam:
> https://github.com/klammerj/atfprog/tree/master/gal_min
>
> You can probably set this up on a breadboard...
>
>
>

LOL !!!

 From the README file:

"Requires ancient computer with parallel port."



Article: 156732
Subject: Re: 22V10 programmer
From: David Brown <david.brown@hesbynett.no>
Date: Mon, 09 Jun 2014 17:01:27 +0200
Links: << >>  << T >>  << A >>
On 09/06/14 16:13, hamilton wrote:
> On 6/8/2014 7:07 PM, Johann Klammer wrote:
>> On 06/08/2014 02:14 PM, hamilton wrote:
>>> Does anyone know of a cheap 22V10 programmer ?
>>>
>>> or maybe a Atmel ATFxxxx programmer ?
>>
>> Oh, thank you.
>> More opportunity to spam:
>> https://github.com/klammerj/atfprog/tree/master/gal_min
>>
>> You can probably set this up on a breadboard...
>>
>>
>>
>
> LOL !!!
>
>  From the README file:
>
> "Requires ancient computer with parallel port."
>
>

Lenevo makes good new computers with parallel ports.  There are also 
quite a few that have a parallel port header on the motherboard, if you 
can scavenge a 25-pin DSUB from an old computer.


Article: 156733
Subject: Re: 22V10 programmer
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Mon, 09 Jun 2014 17:55:28 +0200
Links: << >>  << T >>  << A >>
On 06/09/2014 04:13 PM, hamilton wrote:
> On 6/8/2014 7:07 PM, Johann Klammer wrote:
>
> LOL !!!
>
>  From the README file:
>
> "Requires ancient computer with parallel port."
>
>
Yes, they are getting rare...
You might be able to work with a SMBus port expander or one of those 
FTDI USB things if you don't have a pport... You'll need a 5V tolerant 
port expander...



Article: 156734
Subject: Re: 22V10 programmer
From: hamilton <hamilton@nothere.com>
Date: Mon, 09 Jun 2014 12:36:09 -0600
Links: << >>  << T >>  << A >>
On 6/9/2014 9:55 AM, Johann Klammer wrote:
> On 06/09/2014 04:13 PM, hamilton wrote:
>> On 6/8/2014 7:07 PM, Johann Klammer wrote:
>>
>> LOL !!!
>>
>>  From the README file:
>>
>> "Requires ancient computer with parallel port."
>>
>>
> Yes, they are getting rare...
> You might be able to work with a SMBus port expander or one of those
> FTDI USB things if you don't have a pport... You'll need a 5V tolerant
> port expander...
>
>
Sorry to say, that legacy software the used the parallel port for 
interfacing to the outside world, used direct I/O.

NO, USB device can give the same results as there is no direct I/O 
available.

Been there, done that.

hamilton




Article: 156735
Subject: Re: 22V10 programmer
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Mon, 09 Jun 2014 17:55:45 -0500
Links: << >>  << T >>  << A >>
In article <ln4uqr$g4v$1@dont-email.me>,
 hamilton <hamilton@nothere.com> writes:

>Sorry to say, that legacy software the used the parallel port for 
>interfacing to the outside world, used direct I/O.
>
>NO, USB device can give the same results as there is no direct I/O 
>available.

I assume "direct I/O" is just writing to the output register
and reading the input register.

Is the problem that it can't be made to work, or that it is horribly
slow?  (I'd expect USB writes to take about 1 ms.)

-- 
These are my opinions.  I hate spam.


Article: 156736
Subject: Re: 22V10 programmer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Jun 2014 23:52:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> In article <ln4uqr$g4v$1@dont-email.me>,
> hamilton <hamilton@nothere.com> writes:

(snip)

>>NO, USB device can give the same results as there is no 
>> direct I/O available.
 
> I assume "direct I/O" is just writing to the output register
> and reading the input register.
 
> Is the problem that it can't be made to work, or that it is horribly
> slow?  (I'd expect USB writes to take about 1 ms.)

If it isn't speed, it should be possible with a virtual machine,
to read/write to a virtual parallel port which then maps to a real
USB-parallel adapter.

(I don't know that a specific virtual machine provides that
feature, but it should be possible.)

There are ones that play tricks with the parallel port signals,
especially ones that do input. The original IBM PC wasn't
bidirectional (even though they used a port that could be) but
later ones are.  Some use the status bits (out of paper and such)
as inputs. That might be harder to virtualize.

-- glen
 

Article: 156737
Subject: Re: 22V10 programmer
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 10 Jun 2014 08:17:57 +0200
Links: << >>  << T >>  << A >>
On 10/06/14 01:52, glen herrmannsfeldt wrote:
> Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
>> In article <ln4uqr$g4v$1@dont-email.me>,
>> hamilton <hamilton@nothere.com> writes:
>
> (snip)
>
>>> NO, USB device can give the same results as there is no
>>> direct I/O available.
>
>> I assume "direct I/O" is just writing to the output register
>> and reading the input register.
>
>> Is the problem that it can't be made to work, or that it is horribly
>> slow?  (I'd expect USB writes to take about 1 ms.)
>
> If it isn't speed, it should be possible with a virtual machine,
> to read/write to a virtual parallel port which then maps to a real
> USB-parallel adapter.
>
> (I don't know that a specific virtual machine provides that
> feature, but it should be possible.)
>
> There are ones that play tricks with the parallel port signals,
> especially ones that do input. The original IBM PC wasn't
> bidirectional (even though they used a port that could be) but
> later ones are.  Some use the status bits (out of paper and such)
> as inputs. That might be harder to virtualize.
>

USB parallel ports are at best useful for printers - not for programmers 
or bi-directional IO.

Just buy a computer with a parallel port and save yourself the effort. 
The range with pre-installed parallel ports is small, but at least 
Lenevo have plenty.  The range of motherboards with parallel port 
headers is large - it's just not connected to the back of the PC.  Then 
there are lots of cheaply available parallel port cards you can use on a 
modern PC.  And of course it's not hard to get hold of an old PC 
second-hand.

It's a non-existent problem.

And most software that uses the parallel port will run on FreeDOS (if 
it's DOS based), or Win2000 or earlier - which is easy to install 
without any sort of activations to cause complications (now that XP is 
hard to get as a new license).

VMWare can let a virtual machine use the host machine's parallel port 
directly (I don't believe Virtual Box works with parallel ports, 
unfortunately).



Article: 156738
Subject: Re: 22V10 programmer
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Tue, 10 Jun 2014 10:07:49 +0200
Links: << >>  << T >>  << A >>
On 06/09/2014 08:36 PM, hamilton wrote:
[...]
> Sorry to say, that legacy software the used the parallel port for
> interfacing to the outside world, used direct I/O.
>
> NO, USB device can give the same results as there is no direct I/O
> available.
>
> Been there, done that.
>
> hamilton
>
>
>
Right. You'll have to modify the program to actually work with the 
different hardware. I do not think the programming algorithms are very 
timing sensitive, so hardware-wise it should work even with a serial bus 
in between. You'll want a bi-directional expander with about 16 bits of 
GPIO, not some black-box USB->Printer thing, but an actual chip with 
datasheet.

It all depends on how much time you want to spend...



Article: 156739
Subject: Re: 22V10 programmer
From: hamilton <hamilton@nothere.com>
Date: Tue, 10 Jun 2014 07:38:43 -0600
Links: << >>  << T >>  << A >>
On 6/10/2014 12:17 AM, David Brown wrote:
> On 10/06/14 01:52, glen herrmannsfeldt wrote:
>> Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
>>> In article <ln4uqr$g4v$1@dont-email.me>,
>>> hamilton <hamilton@nothere.com> writes:
>>
>> (snip)
>>
>>>> NO, USB device can give the same results as there is no
>>>> direct I/O available.
>>
>>> I assume "direct I/O" is just writing to the output register
>>> and reading the input register.
>>
>>> Is the problem that it can't be made to work, or that it is horribly
>>> slow?  (I'd expect USB writes to take about 1 ms.)
>>
>> If it isn't speed, it should be possible with a virtual machine,
>> to read/write to a virtual parallel port which then maps to a real
>> USB-parallel adapter.
>>
>> (I don't know that a specific virtual machine provides that
>> feature, but it should be possible.)
>>
>> There are ones that play tricks with the parallel port signals,
>> especially ones that do input. The original IBM PC wasn't
>> bidirectional (even though they used a port that could be) but
>> later ones are.  Some use the status bits (out of paper and such)
>> as inputs. That might be harder to virtualize.
>>
>
> USB parallel ports are at best useful for printers - not for programmers
> or bi-directional IO.
>
> Just buy a computer with a parallel port

Kind of misses the point that the OP asked for cheap device programmer.

"Yes, its cheap, you just need to buy a $500 computer to make it work."

and save yourself the effort.
> The range with pre-installed parallel ports is small, but at least
> Lenevo have plenty.  The range of motherboards with parallel port
> headers is large - it's just not connected to the back of the PC.  Then
> there are lots of cheaply available parallel port cards you can use on a
> modern PC.  And of course it's not hard to get hold of an old PC
> second-hand.
>
> It's a non-existent problem.
>
> And most software that uses the parallel port will run on FreeDOS (if
> it's DOS based), or Win2000 or earlier - which is easy to install
> without any sort of activations to cause complications (now that XP is
> hard to get as a new license).
>
> VMWare can let a virtual machine use the host machine's parallel port
> directly (I don't believe Virtual Box works with parallel ports,
> unfortunately).
>
>


Article: 156740
Subject: Re: HELP: Edge triggering of mode register, Verilog
From: Bruce Varley
Date: Tue, 10 Jun 2014 22:36:58 +0800
Links: << >>  << T >>  << A >>
On Sun, 08 Jun 2014 08:21:19 -0500, "mnentwig" <24789@embeddedrelated>
wrote:

>Hi,
>
>one line was missing:
>
>input wire switch;
>reg switchPrev = 0;
>wire switchOn = (switch & !switchPrev);
>wire switchOff = (!switch && switchPrev);
>reg pump = 0;
>
>always @(posedge clk) begin
>  switchPrev <= switch;
>  if (switchOn) begin pump <= 1; end
>  if (switchOff) begin pump <= 0; end
>end
>
>What's important to know is that "<=" assignments only becomes effective
>after the ongoing clock cycle has completed. The wire "=" assignments in
>this example are combinational logic and cause zero delay.  
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com

Thanks. I'm designing it as a state machine (I use them already for
industrial sequencing applications). This is a good illustration of
how the state model sometimes has a shape that differs from what you
think it might be. Cheers

    

Article: 156741
Subject: Re: 22V10 programmer
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 10 Jun 2014 23:51:15 +0200
Links: << >>  << T >>  << A >>
On 10/06/14 15:38, hamilton wrote:
> On 6/10/2014 12:17 AM, David Brown wrote:
>> On 10/06/14 01:52, glen herrmannsfeldt wrote:
>>> Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
>>>> In article <ln4uqr$g4v$1@dont-email.me>,
>>>> hamilton <hamilton@nothere.com> writes:
>>>
>>> (snip)
>>>
>>>>> NO, USB device can give the same results as there is no
>>>>> direct I/O available.
>>>
>>>> I assume "direct I/O" is just writing to the output register
>>>> and reading the input register.
>>>
>>>> Is the problem that it can't be made to work, or that it is horribly
>>>> slow?  (I'd expect USB writes to take about 1 ms.)
>>>
>>> If it isn't speed, it should be possible with a virtual machine,
>>> to read/write to a virtual parallel port which then maps to a real
>>> USB-parallel adapter.
>>>
>>> (I don't know that a specific virtual machine provides that
>>> feature, but it should be possible.)
>>>
>>> There are ones that play tricks with the parallel port signals,
>>> especially ones that do input. The original IBM PC wasn't
>>> bidirectional (even though they used a port that could be) but
>>> later ones are.  Some use the status bits (out of paper and such)
>>> as inputs. That might be harder to virtualize.
>>>
>>
>> USB parallel ports are at best useful for printers - not for programmers
>> or bi-directional IO.
>>
>> Just buy a computer with a parallel port
>
> Kind of misses the point that the OP asked for cheap device programmer.
>
> "Yes, its cheap, you just need to buy a $500 computer to make it work."
>

I missed the "cheap" part - I've seen people looking for /anything/ at 
pretty much /any/ price that will still work with their old parallel 
port stuff.

But I would be surprised if you can't get an old used PC for $50 that 
would have a parallel port and do the job, so it's not a completely 
wasted suggestion.

> and save yourself the effort.
>> The range with pre-installed parallel ports is small, but at least
>> Lenevo have plenty.  The range of motherboards with parallel port
>> headers is large - it's just not connected to the back of the PC.  Then
>> there are lots of cheaply available parallel port cards you can use on a
>> modern PC.  And of course it's not hard to get hold of an old PC
>> second-hand.
>>
>> It's a non-existent problem.
>>
>> And most software that uses the parallel port will run on FreeDOS (if
>> it's DOS based), or Win2000 or earlier - which is easy to install
>> without any sort of activations to cause complications (now that XP is
>> hard to get as a new license).
>>
>> VMWare can let a virtual machine use the host machine's parallel port
>> directly (I don't believe Virtual Box works with parallel ports,
>> unfortunately).
>>
>>
>


Article: 156742
Subject: Re: 22V10 programmer
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 11 Jun 2014 12:43:27 +0100 (BST)
Links: << >>  << T >>  << A >>
Johann Klammer <klammerj@nospam.a1.net> wrote:
> Right. You'll have to modify the program to actually work with the 
> different hardware. I do not think the programming algorithms are very 
> timing sensitive, so hardware-wise it should work even with a serial bus 
> in between. You'll want a bi-directional expander with about 16 bits of 
> GPIO, not some black-box USB->Printer thing, but an actual chip with 
> datasheet.
> 
> It all depends on how much time you want to spend...

I think attempting to do low latency, timing-sensitive I/O over USB these
days is a lost cause, and has been for years.  But today's solution might be
to stick an Arduino, Raspberry Pi or whatever on the end of the cable and
have that handle the I/O.

The main awkwardness is code that expects DOS-style I/O (eg writing directly
to parallel port registers using IN and OUT) or is lacking in source code to
port to such platforms.

Theo

Article: 156743
Subject: MachXO primary clock example (PCLK)
From: gergo.santha@gmail.com
Date: Fri, 13 Jun 2014 04:48:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi!

I'd like to use an external 25MHz TCXO as a primary clock. Unfortunately, t=
he application notes (at least what I've found) are very laconic on this to=
pic. The only examples are of the OSCC module which is an internal oscillat=
or. According to the MachXO datasheet any pin can be used as a clock input =
but the preferred way is to connect external clock signals to the dedicated=
 clock pins. It is clear that there are primary clock pins on the device an=
d I can feed the TCXO's output into one of them. But how can I refer to thi=
s primary clock in my Verilog code? It is also not clear how can I change t=
hat the primary clock input pins are clock pins and not the default I/O pin=
s...in the Spreadsheet tab, I couldn't find it.

Thank you in advance,

G

Article: 156744
Subject: Need help to provide input/output timing constraint for DDR Interface
From: "kapatel" <94438@embeddedrelated>
Date: Fri, 13 Jun 2014 08:01:01 -0500
Links: << >>  << T >>  << A >>
Hi All,

I am working on SD Card IP Core for Altera FPGA which has DDR
interface.Input and Output Timing requirements for SD Card is given below

tISUddr (Input Setup Time) = 2.5ns,
tIHddr (Input Hold Time) = 2.5ns,
tODLYddr_max(Output tCO Maximum) = 7ns,
tODLYddr_min(Output tCO Minimum) = 1.5ns,
tPP(Clock Period) = 20ns

I have given timing constraint to Input/Output port in following manner.

//Clock Constraint

create_clock -name CLK -period 20ns [get_ports{CLK}]

//Input Delay Constraint

set_input_delay -clock { CLK } -max -add_delay $tODLYddr_max [get_ports
{SD_DATA*}]
set_input_delay -clock { CLK } -min -add_delay -$tODLYddr_min [get_ports
{SD_DATA*}]

set_input_delay -clock { CLK } -clock_fall -max -add_delay $tODLYddr_max
[get_ports {SD_DATA*}]
set_input_delay -clock { CLK } -clock_fall -min -add_delay -$tODLYddr_min
[get_ports {SD_DATA*}]

//Set False path between rising edge of CLK to falling edge of CLK

set_false_path -setup -rise_from [get_clocks {CLK}] -fall_to [get_clocks
{CLK}]
set_false_path -setup -fall_from [get_clocks {CLK}] -rise_to [get_clocks
{CLK}]
set_false_path -hold -fall_from [get_clocks {CLK}] -fall_to [get_clocks
{CLK}]
set_false_path -hold -rise_from [get_clocks {CLK}] -rise_to [get_clocks
{CLK}]

//Output Delay Constraint

set_input_delay -clock { CLK } -max -add_delay $tISUddr [get_ports
{SD_DATA*}]
set_input_delay -clock { CLK } -min -add_delay -$tIHddr [get_ports
{SD_DATA*}]

set_input_delay -clock { CLK } -clock_fall -max -add_delay $tISUddr
[get_ports {SD_DATA*}]
set_input_delay -clock { CLK } -clock_fall -min -add_delay -$tIHddr
[get_ports {SD_DATA*}]

//Set False path between rising edge of CLK to falling edge of CLK

set_false_path -setup -rise_from [get_clocks {CLK}] -fall_to [get_clocks
{CLK}]
set_false_path -setup -fall_from [get_clocks {CLK}] -rise_to [get_clocks
{CLK}]
set_false_path -hold -fall_from [get_clocks {CLK}] -fall_to [get_clocks
{CLK}]
set_false_path -hold -rise_from [get_clocks {CLK}] -rise_to [get_clocks
{CLK}]

//ALTDDIO BIDIR Megafunction Instance

alt_ddio_bidir inst
(
//DDIO Out Port

outclock (CLK),
datain_h (data_out_h),
datain_l (data_out_l),

oe (dir),

//DDIO In Port

inclock (CLK),
dataout_h (data_in_h),
dataou_l (data_in_l)
);

Here CLK is used to generate data_out_h and data_out_l signals during write
operation and the same CLK is used to capture
data_in_h and data_in_l signals.Same CLK is given to SD Card also.


Is these timing constraints are correct?

I refer some Altera's document in which center align or phase shifted clock
is used to provide input/output delay constraint.

Is it mandatory to use different launch and latch clock in case of DDR data
interface?


Thanks in advance. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156745
Subject: Re: Need help to provide input/output timing constraint for DDR Interface
From: "kapatel" <94438@embeddedrelated>
Date: Fri, 13 Jun 2014 08:19:56 -0500
Links: << >>  << T >>  << A >>
Forgot to mention that Setup,Hold and tCO time are same for both rising and
falling edge of the CLK.

>Hi All,
>
>I am working on SD Card IP Core for Altera FPGA which has DDR
>interface.Input and Output Timing requirements for SD Card is given below
>
>tISUddr (Input Setup Time) = 2.5ns,
>tIHddr (Input Hold Time) = 2.5ns,
>tODLYddr_max(Output tCO Maximum) = 7ns,
>tODLYddr_min(Output tCO Minimum) = 1.5ns,
>tPP(Clock Period) = 20ns
>
>I have given timing constraint to Input/Output port in following manner.
>
>//Clock Constraint
>
>create_clock -name CLK -period 20ns [get_ports{CLK}]
>
>//Input Delay Constraint
>
>set_input_delay -clock { CLK } -max -add_delay $tODLYddr_max [get_ports
>{SD_DATA*}]
>set_input_delay -clock { CLK } -min -add_delay -$tODLYddr_min [get_ports
>{SD_DATA*}]
>
>set_input_delay -clock { CLK } -clock_fall -max -add_delay $tODLYddr_max
>[get_ports {SD_DATA*}]
>set_input_delay -clock { CLK } -clock_fall -min -add_delay -$tODLYddr_min
>[get_ports {SD_DATA*}]
>
>//Set False path between rising edge of CLK to falling edge of CLK
>
>set_false_path -setup -rise_from [get_clocks {CLK}] -fall_to [get_clocks
>{CLK}]
>set_false_path -setup -fall_from [get_clocks {CLK}] -rise_to [get_clocks
>{CLK}]
>set_false_path -hold -fall_from [get_clocks {CLK}] -fall_to [get_clocks
>{CLK}]
>set_false_path -hold -rise_from [get_clocks {CLK}] -rise_to [get_clocks
>{CLK}]
>
>//Output Delay Constraint
>
>set_input_delay -clock { CLK } -max -add_delay $tISUddr [get_ports
>{SD_DATA*}]
>set_input_delay -clock { CLK } -min -add_delay -$tIHddr [get_ports
>{SD_DATA*}]
>
>set_input_delay -clock { CLK } -clock_fall -max -add_delay $tISUddr
>[get_ports {SD_DATA*}]
>set_input_delay -clock { CLK } -clock_fall -min -add_delay -$tIHddr
>[get_ports {SD_DATA*}]
>
>//Set False path between rising edge of CLK to falling edge of CLK
>
>set_false_path -setup -rise_from [get_clocks {CLK}] -fall_to [get_clocks
>{CLK}]
>set_false_path -setup -fall_from [get_clocks {CLK}] -rise_to [get_clocks
>{CLK}]
>set_false_path -hold -fall_from [get_clocks {CLK}] -fall_to [get_clocks
>{CLK}]
>set_false_path -hold -rise_from [get_clocks {CLK}] -rise_to [get_clocks
>{CLK}]
>
>//ALTDDIO BIDIR Megafunction Instance
>
>alt_ddio_bidir inst
>(
>//DDIO Out Port
>
>outclock (CLK),
>datain_h (data_out_h),
>datain_l (data_out_l),
>
>oe (dir),
>
>//DDIO In Port
>
>inclock (CLK),
>dataout_h (data_in_h),
>dataou_l (data_in_l)
>);
>
>Here CLK is used to generate data_out_h and data_out_l signals during
write
>operation and the same CLK is used to capture
>data_in_h and data_in_l signals.Same CLK is given to SD Card also.
>
>
>Is these timing constraints are correct?
>
>I refer some Altera's document in which center align or phase shifted
clock
>is used to provide input/output delay constraint.
>
>Is it mandatory to use different launch and latch clock in case of DDR
data
>interface?
>
>
>Thanks in advance. 	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156746
Subject: Re: 22V10 programmer
From: jg <j.m.granville@gmail.com>
Date: Sat, 14 Jun 2014 21:17:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 9, 2014 12:14:09 AM UTC+12, hamilton wrote:
> Does anyone know of a cheap 22V10 programmer ?
> 
> or maybe a Atmel ATFxxxx programmer ?

22V10 parts need a device programmer, and the better ones of those are >> $100 for USB models. (eg ChipMAX2)

If you do not _need_ 22V10 but are ok with ATF15xx 44 pin parts, those have JTAG programming and can pgm using a FT2232D or FT2232H board.  ( ~$27 )


Article: 156747
Subject: Re: 22V10 programmer
From: Dave <g4ugm@btinternet.com>
Date: Sun, 15 Jun 2014 23:55:26 +0100
Links: << >>  << T >>  << A >>
On 15/06/2014 05:17, jg wrote:
> On Monday, June 9, 2014 12:14:09 AM UTC+12, hamilton wrote:
>> Does anyone know of a cheap 22V10 programmer ?
>>
>> or maybe a Atmel ATFxxxx programmer ?
>
> 22V10 parts need a device programmer, and the better ones of those are >> $100 for USB models. (eg ChipMAX2)
>
> If you do not _need_ 22V10 but are ok with ATF15xx 44 pin parts, those have JTAG programming and can pgm using a FT2232D or FT2232H board.  ( ~$27 )
>
The G540 USB seems to do these at a reasonable price...

Article: 156748
Subject: Re: 22V10 programmer
From: hamilton <hamilton@nothere.com>
Date: Sun, 15 Jun 2014 17:22:06 -0600
Links: << >>  << T >>  << A >>
On 6/15/2014 4:55 PM, Dave wrote:
> On 15/06/2014 05:17, jg wrote:
>> On Monday, June 9, 2014 12:14:09 AM UTC+12, hamilton wrote:
>>> Does anyone know of a cheap 22V10 programmer ?
>>>
>>> or maybe a Atmel ATFxxxx programmer ?
>>
>> 22V10 parts need a device programmer, and the better ones of those are
>> >> $100 for USB models. (eg ChipMAX2)
>>
>> If you do not _need_ 22V10 but are ok with ATF15xx 44 pin parts, those
>> have JTAG programming and can pgm using a FT2232D or FT2232H board.  (
>> ~$27 )
>>
> The G540 USB seems to do these at a reasonable price...
Thanks all,

I have the G540 USB on order now.

H


Article: 156749
Subject: Re: PLA? PAL? PLD? GAL?
From: azimalimoll@gmail.com
Date: Mon, 16 Jun 2014 11:59:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, February 18, 1995 9:26:05 AM UTC+5:30, u801...@cc.nctu.edu.tw wrote:
> Hello,
> 
> I would like to know something diffrent among them? I was always cunfused
> by them all.
> 
> In my previous impression, they are:
> 
> PAL: programmable AND, fixed OR
> PLD: programmable AND, programmable OR
> PLA: ???????????? AND, ???????????? OR
> GAL=PLD ??
> 
> Please correct the above, Thanks in advance!
> 
> 					Jason




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
2017JanFebMarApr2017

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