Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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.comArticle: 156727
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
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
> > 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 TelematicsArticle: 156730
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.comArticle: 156731
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
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
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
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. hamiltonArticle: 156735
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
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. -- glenArticle: 156737
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
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
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
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: 156741On 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
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. TheoArticle: 156743
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, GArticle: 156744
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
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: 156746On 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
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
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. HArticle: 156749
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:
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