Author Topic: Beginner FPGA dev board  (Read 33926 times)

0 Members and 1 Guest are viewing this topic.

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #50 on: December 04, 2015, 10:04:59 am »
VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!
I think it is more like telling a 'C' newbie not to use malloc() and free() until they have a firm understanding of the basic language.

The difference is that unlike 'C' without malloc() and free(), following the above rules you can still write anything that can be synthesized in an FPGA, and still keeping within VHDL's strong typing paradigm.

Not really. If you want to continue the analogy without looking at the larger picture, then realise that malloc/free are part of a library not the C language. So not using malloc/free is(if anything) equivalent to not using a PLL/clock multiplier or FIFO.

Quote
Every time I see VHDL code with an integer port definition on a module a little part of me cries...

I guess your clause of "...and should, where beneficial" is the key.... I can't think of many cases where doing anything else is beneficial!

Reread the first part of the sentence to get an inkling of the "many" cases where it is useful.

I would guess that you have only been involved in implementing devices, never designing them - especially in a system context. Consider especially the design validation phase, which as I presume you know, occurs well in advance of the implementation and verification phases. Using the same tool for validation and verification has significant advantages, which is one reason why VHDL's "architecture X of entity Y" concept exists.

If you want a trivial pedagogical DSP example from my dim and distant past when DSP blocks didn't exist, consider having to implement a module that computes "x - 4*y + 640" in a single clock cycle. Integers are the natural representation of what is intended and meant, so use them! And always use them in the test bench, of course.

You should also consider that simulations of integers (for example) can run faster than simulations of gates, since they map directly onto the CPUs instructions. That can be very significant in large designs. Later on the "integer processing" is incrementally replaced by its gate-level equivalent, via adding other architectures to individual models.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 948
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: Beginner FPGA dev board
« Reply #51 on: December 04, 2015, 10:44:35 am »
As with every new language, I first need to get past the point where I need to lookup every other word  ::)

Then I will start to think about structure and patterns & practices. I'm still in the "hello world" stage.
The VGA- and glue-logic I am wanting to make should not be to create for I have already found several examples - on the other hand I will want to really understand why it works. But I will probably lean toward the more high-level take on the language - simply to offload some of the details to the compiler/synthesizer.

For now I am content when what I type compiles  :-DD
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #52 on: December 04, 2015, 11:03:50 am »
As with every new language, I first need to get past the point where I need to lookup every other word  ::)

Then I will start to think about structure and patterns & practices. I'm still in the "hello world" stage.
The VGA- and glue-logic I am wanting to make should not be to create for I have already found several examples - on the other hand I will want to really understand why it works. But I will probably lean toward the more high-level take on the language - simply to offload some of the details to the compiler/synthesizer.

For now I am content when what I type compiles  :-DD

Sounds familiar!

As I'm sure you will discover, one HDL is much like another HDL in the same way one procedural HLL is much like another procedural HLL. But of course there are very significant differences between HLLs and HDLs. However, arguably some enterprise-level and cloud-level environments are becoming more like HDLs in that they emphasise structural composition of pre-existing building blocks; about time too :)

As you note, the trick is to understand what they are and aren't doing for you.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 1099
  • Country: us
    • KE5FX.COM
Re: Beginner FPGA dev board
« Reply #53 on: December 04, 2015, 11:04:12 am »
Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair. |O  Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: lt
Re: Beginner FPGA dev board
« Reply #54 on: December 04, 2015, 02:24:15 pm »
Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed. FPGA design is difficult for beginner and takes years of time to learn. I remember spending days and weeks solving some issues, especially when getting IP from somewhere else and finishing up rewriting everything from scratch.
It takes lots of theory, lots of practice, failures and successes to reach a level where you feel confident. And after 3 years of HDL design I felt that I don't know so many things... On the other hand, that's why it's so awesome and interesting!

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair. |O  Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #55 on: December 04, 2015, 03:57:33 pm »
Finite State machine - usually implemented with a large case statement. The two-process style works very well for state machines

For fuck's sake stop with the recommendations that anyone use a two-process state machine. Totally error prone, easy to screw up, difficult to maintain.

The new user should always use the single synchronous process for state machines, and use a two-process machine only if there's a Real Good Reason and he knows what he's doing.

Agreed with Bassman59 here.  A newbie to FPGA development will encounter decades' worth of "received wisdom" regarding how to write HDL.  Trouble is, virtually all of this received wisdom was transmitted by people who were designing ASICs 20 years ago.  The distinction between Mealy and Moore state machines, whether you should modify your state in the same process as the rest of the FSM, how to implement resets, and how to avoid the mortal sin of creating latches... almost everything you will find in textbooks and on the Web regarding these topics and many more is obsolete and not worth a moment's thought. 

Unfortunately you won't learn what can/should be ignored until you gain some experience, and you won't gain experience without tearing out a lot of your own hair. |O  Get used to feeling like Gandalf one minute and all three of the Stooges the next.  That's what FPGA work is like.

This advice and is timeless, and applies to hardware, software and I'm sure many other endeavours:
  • make it so that the implementation transparently and directly corresponds to the high-level design
  • when, not if, the high-level design mutates in the light of experience or new requirements, ensure that the implementation technique allows easy and simple modifications in which the desired changes and only the desired changes, occur
  • such changes should include the addition of new states, adding/subtracting events to a state, changing the processing when an event occurs
  • ensure the implementation technique allows easy debugging, which must include seeing which events occurred in which state and in which order. That has the bonus that it can make it easy to prove that another module is misbehaving, which is especially valuable if the other module is from another company!
  • use common well-supported tools for defining the FSM; don't invent yet another FSM description language - unless you are prepared to provide tool support and train new people in its use
You may take a hit in the short term, but in the long term those techniques have been very valuable to me personally and to other people in several companies.

For VHDL FSMs, the two process techique is one suitable design pattern. There are valid other design patterns, but they should also be measured against the above criteria.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #56 on: December 05, 2015, 02:48:50 am »
About to start a flame war I guess...
The only one you want is
 use IEEE.NUMERIC_STD.ALL;
......
And always keep your module's external interfaces as STD_LOGIC or STD_LOGIC_VECTOR. This keeps the higher level structural modules clean of random data types. It is OK for a module's generics to be integers or naturals.

Follow these guidelines and pretty much all your data type problems will go away.

...but you might lose other benefits.

VHDL can be used to model concepts higher than bits and numbers, just as any modern software language can. And should, where beneficial.

Your advice is equivalent to telling a C programmer to only use ints and longs, and that all type conversion problems associated with structs and typedefs will go away. While that is true, you are also "throwing the baby out with the bathwater"!

Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #57 on: December 05, 2015, 02:50:57 am »
I couldn't find any decent language/syntax reference or IEEE library documentation which made it harder than it had to be. I also found that not all IEEE libraries are the same!? I got an error that no '+' operator was on a std_logic type (Altera), while I saw examples for Xilinx (or other) do just that... (count = count + 1)
You can always switch to Verilog and enjoy a complete lack of typing :)

Quote
with a much-improved mental model of what I was doing from then on
I think that's why they taught me the three process fsm. Overkill? Yes! But you can see the basic principle.

I've seen some truly dreadful implementations of FSMs in my time which had such deeply nested case and if statements that, when they had to be slightly modified, people couldn't be sure that their change didn't affect more than they expected. Bad design and implementation, sure - but it instills a strong desire to write code that is readable and easily mutatable.

The two and three process patterns are an excellent way of encouraging and aiding that objective.
As with most coding its best to be pragmatic and write code that works and is understandable rather than have rules. I've not seen many straight multiprocess designs in the wild and its often much clearer to mix styles within a single FSM. The tools have advanced enough that they can extract the state map from just about anything and I'm not having to try and coerce the synthesis to infer what I want anymore.

Exactly.

The original reason for the two- (and three-) process state machine was that Synopsys didn't support it back in the early 90s. Once better synthesis tools became available, that arbitrary limit went away.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2177
  • Country: nz
Re: Beginner FPGA dev board
« Reply #58 on: December 05, 2015, 08:47:13 am »
Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.

I must be missing something. Can you point me at a sizable project that uses the techniques you are suggesting, so I can look through the code?

But for now, here is my experiment I performed tonight. For a project I am working on. I get a 12-bit value from an ADC, and I need to scale an ADC reading by 503.75/4096 (or 2015/16348). So I coded it both ways, and implemented it in hardware.

So if I understand your suggested style, using integers or naturals on the interface makes sense, doubly so to a HDL newbie. It also makes sense to use '*' and '/' operators too.

Code: [Select]
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity using_ints is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in integer;
           temp        : out integer);
end using_ints;

architecture Behavioral of using_ints is
begin

process(clk)
    begin
        if rising_edge(clk) then
            temp <= adc_reading * 2015 / 16384;
        end if;
    end process;

end Behavioral;
Perfectly reasonable code, and implements and tests correctly. With the inputs and output registered outside of the his module, the usage within the module is 60 LUTs, 9 Flipflops, 1 DSP block, Fmax 117 MHz. I also tried it with 'naturals' rather than integers, with the same results.

Now using STD_LOGIC_VECTOR as the interface, and hinting at what is really efficient to do.

Code: [Select]
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity using_slv is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in STD_LOGIC_VECTOR (11 downto 0);
           tempx        : out STD_LOGIC_VECTOR (8 downto 0));
end using_slv;

architecture Behavioral of using_slv is

    signal adc_reading_x2048 : unsigned (22 downto 0);
    signal adc_reading_x32   : unsigned (16 downto 0);
    signal adc_reading_x1    : unsigned (11 downto 0);
    signal result            : unsigned (22 downto 0);
begin
    adc_reading_x2048 <= unsigned(adc_reading) & to_unsigned(0,11); 
    adc_reading_x32   <= unsigned(adc_reading) & to_unsigned(0,5); 
    adc_reading_x1    <= unsigned(adc_reading); 
    temp              <= std_logic_vector(result(result'high downto 14));   -- Divide by 2^14 = 16k

process(clk)
    begin
       if rising_edge(clk) then
         result <= adc_reading_x2048 - adc_reading_x32 - adc_reading_x1;
       end if;
    end process;   
end Behavioral;

Module usage 23 LUTs, 8 Flipflops, Fmax 384 MHz - less than half the LUTs, no DSP blocks, and three times faster.

To me, the results speak for themselves...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #59 on: December 05, 2015, 10:02:34 am »
The original reason for the two- (and three-) process state machine was that Synopsys didn't support it back in the early 90s. Once better synthesis tools became available, that arbitrary limit went away.

While one particular tool may not have supported a particular design pattern at some time in the past, that is neither a reason to use nor to avoid the design pattern.

Ob joke: "Mummy, why do you cut the end off the leg of lamb before roasting it?". "Because that the way granny always did it; why don't you ask her?". Granny looks puzzled, then remembers "Because I had to do that to fit it in the small oven".

The key points about a design pattern is that it is easily recognisable, understandable, supports good design/implementation/modification practices. Two process FSM are one such design pattern, and it is perfectly reasonable to continue to use it.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10501
  • Country: gb
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #60 on: December 05, 2015, 10:06:15 am »
Bassman59: you might like to reflect that you seem to be getting a reputation, viz https://www.eevblog.com/forum/open-source-kicad-geda/the-new-version-of-kicad-is-a-fact/msg814376/#msg814376
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #61 on: December 08, 2015, 05:17:29 am »
Look at this ... I agree with you! Restricting entity ports to std_logic and std_logic_vector puts arbitrary limits on a design. Use natural, unsigned, signed, wherever they make sense. At the very least, doing so reduces the number of type conversions that everyone seems to hate.

I must be missing something. Can you point me at a sizable project that uses the techniques you are suggesting, so I can look through the code?

But for now, here is my experiment I performed tonight. For a project I am working on. I get a 12-bit value from an ADC, and I need to scale an ADC reading by 503.75/4096 (or 2015/16348). So I coded it both ways, and implemented it in hardware.

So if I understand your suggested style, using integers or naturals on the interface makes sense, doubly so to a HDL newbie. It also makes sense to use '*' and '/' operators too.

Code: [Select]
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity using_ints is
    Port ( clk         : in STD_LOGIC;
           adc_reading : in integer;
           temp        : out integer);
end using_ints;

architecture Behavioral of using_ints is
begin

process(clk)
    begin
        if rising_edge(clk) then
            temp <= adc_reading * 2015 / 16384;
        end if;
    end process;

end Behavioral;
Perfectly reasonable code, and implements and tests correctly. With the inputs and output registered outside of the his module, the usage within the module is 60 LUTs, 9 Flipflops, 1 DSP block, Fmax 117 MHz. I also tried it with 'naturals' rather than integers, with the same results.

Rookie mistake: You used integer for the ports. Without a range, an integer is 32 bits wide. In your std_logic_vector example, the vector sizes are 12 bits for the input and 9 bits for the output. Since the integer operations are all 32 bits wide, of course you will have a lot of extra logic and as such lower performance.

Using a ranged integer (or natural) on a port can be cumbersome, as you need to declare a subtype with the range and for that subtype to be visible in the top-level entity as well as the lower-level, you need to put it in a package.

A better solution would be to not use an integer type, but instead use the unsigned type from numeric_std. You can declare the ports as an unsigned(11 downto 0) and unsigned(9 downto 0) instead of std_logic_vector, saving yourself the type conversion. numeric_std overloads the usual math operators for unsigned, and you can also manipulate the vectors like you did in your second example.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #62 on: December 08, 2015, 05:24:06 am »
Bassman59: you might like to reflect that you seem to be getting a reputation, viz https://www.eevblog.com/forum/open-source-kicad-geda/the-new-version-of-kicad-is-a-fact/msg814376/#msg814376

I know; I read the thread. Apparently, the snake person thinks I am some sort of God. That's his delusion, and he is projecting. Basically, he assigns to me the same stringent adherence to dogma that he holds himself. My argument is not that "My Way Is The Only Way," but he seems to think it so. Whatever. He is welcome to re-invent the wheel with every design.

As for the two-process state machine, that is a design idiom up with which I will not put! The record idea is clever, but I don't see how it offers an advantage over the single synchronous process. After all, you're going to register your machine outputs and the state variable, anyway.
 

Offline alan.green@gmail.com

  • Supporter
  • ****
  • Posts: 12
  • Country: au
Re: Beginner FPGA dev board
« Reply #63 on: December 08, 2015, 09:50:52 am »
Does anyone have thoughts on the FleaFPGA Uno?

http://www.fleasystems.com/fleaFPGA_Uno.html

On the plus side, it is programmable via USB, has HDMI and USB connectors on-board, and does ADC. On the negative side, with the Arduino form factor, there aren't a lot of spare GPIO pins.
 

Offline alexanderbrevig

  • Frequent Contributor
  • **
  • Posts: 588
  • Country: no
  • Musician, programmer and EE hobbyist
    • alexanderbrevig.com
Re: Beginner FPGA dev board
« Reply #64 on: December 08, 2015, 09:56:20 am »

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 639
  • Country: au
Re: Beginner FPGA dev board
« Reply #65 on: December 09, 2015, 02:10:50 am »
Was expecting to hear something about the ARTY that was in recent mailbag vlog.
 

Offline nixfu

  • Supporter
  • ****
  • Posts: 344
  • Country: us
Re: Beginner FPGA dev board
« Reply #66 on: December 14, 2015, 12:55:15 pm »
Just purchased this dev board from china.

$37 for a fully stocked dev board with an Altera Cyclone IV seemed like a decent price. It has onboard LED's, LCD, 7segs, buttons, switches, speaker, VGA out, and more..it even includes a USB blaster.

http://www.aliexpress.com/item/USB-BLASTER-LCD1602-ALTERA-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/793643076.html

 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2556
  • Country: gb
Re: Beginner FPGA dev board
« Reply #67 on: December 15, 2015, 09:11:38 pm »
My $37 Cyclone IV board and accessories arrived from China this morning!  :-+

One thing I am really happy with is the included clone Altera USB blaster actually works perfectly in Windows 10. I initially thought this part was redundant, as I had one already, but for the bargain price of the whole kit, what the hell? Same goes for the TTL UART. I've got a couple already.

My old USB Blaster worked in Win 7 and Linux but would hang in Win 10 and/or blue screen. This new one works perfectly. So glad because it has been such a pain rebooting to Linux when I fancy doing some FPGA...

My old cheap-arse clone USB Blaster was STM32 based with a 8MHz crystal (red PCB). This new one is PIC18 and 12MHz crystal (green PCB).



Oh, and the dev board appears to work just fine  :-+



 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2556
  • Country: gb
Re: Beginner FPGA dev board
« Reply #68 on: December 15, 2015, 09:29:15 pm »
Oh, for anyone interested in the documentation, schematics, and code for this board I have rehosted it on MEGA (NZ) because the Chinese guys link you get by email is really slow! I hope this works, it's quite big!

https://mega.nz/#!PI9wQAAK!h9lfFgYkCeyqfmOMDonJX90HvoenrujtsatB8H_a7co
« Last Edit: December 15, 2015, 09:35:28 pm by Macbeth »
 
The following users thanked this post: denimdragon

Offline MagicSmoker

  • Super Contributor
  • ***
  • Posts: 1396
  • Country: us
Re: Beginner FPGA dev board
« Reply #69 on: December 15, 2015, 10:53:40 pm »
Oh, for anyone interested in the documentation, schematics, and code for this board I have rehosted it on MEGA (NZ) because the Chinese guys link you get by email is really slow! I hope this works, it's quite big!
(url snipped)

Thanks for reporting on your experience and hosting the documentation; I'm buying one of these boards right now because of this.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: Beginner FPGA dev board
« Reply #70 on: December 15, 2015, 11:46:44 pm »
164MB is not big at all :)

Thanks for posting.

Tempted although I have too many dev boards already. Too bad the VGA only has one bit per color. It wouldn't have cost them much to add a three bit per color R2R ladder.

 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2556
  • Country: gb
Re: Beginner FPGA dev board
« Reply #71 on: December 16, 2015, 12:00:15 am »
I'm happy just to count some 7-segs and mess with a 1602 LCD for £24... That VGA voodoo is mind blowing to me... for now! :-DD
 

Offline MagicSmoker

  • Super Contributor
  • ***
  • Posts: 1396
  • Country: us
Re: Beginner FPGA dev board
« Reply #72 on: December 16, 2015, 11:16:13 pm »
...
Thanks for reporting on your experience and hosting the documentation; I'm buying one of these boards right now because of this.

Well, so much for that... Aliexpress cancelled my order due to "insufficient documentation" but failed to tell me what documentation I needed. My credit card issuer says they didn't decline the charge so who knows what went wrong. This was my first, and it looks like it will be my last, experience with Aliexpress.

 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2556
  • Country: gb
Re: Beginner FPGA dev board
« Reply #73 on: December 16, 2015, 11:26:18 pm »
Bizarre!... But if you want to can the whole of China marketed via AliExpress all over a single fuck up with your one and only credit card issuer then so be it  :palm:

I think it goes without saying that Special Snowflakes need not try and deal with anything other than home grown stuff like Sparkfun!  :-/O ... and if really risking it, ebay, but don't tell Mom!

I will just say I have had some Ali sellers that have been scammers to say the least, but I knew I was entering the dragons den in those transactions AND GOT FULL REFUNDS.

This particular seller is A1 by all accounts. A little slow to get the stuff sent, but when it is it is fully tracked and takes about a month all in. That is pretty much par for the course with China.
« Last Edit: December 16, 2015, 11:30:04 pm by Macbeth »
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2177
  • Country: nz
Re: Beginner FPGA dev board
« Reply #74 on: December 17, 2015, 03:17:52 am »
Well, so much for that... Aliexpress cancelled my order due to "insufficient documentation" but failed to tell me what documentation I needed. My credit card issuer says they didn't decline the charge so who knows what went wrong. This was my first, and it looks like it will be my last, experience with Aliexpress.

I've decided that I really do want an relatively inexpensive USB Blaster clone, and the board will be just a bonus, so ordered one. I'll let you know if I have any issues with my credit card...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf