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

0 Members and 1 Guest are viewing this topic.

Online KE5FX

  • Super Contributor
  • ***
  • Posts: 1878
  • Country: us
    • KE5FX.COM
Re: Beginner FPGA dev board
« Reply #50 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: 797
  • Country: lt
Re: Beginner FPGA dev board
« Reply #51 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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #52 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: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #53 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: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #54 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.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #55 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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #56 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
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Beginner FPGA dev board
« Reply #57 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: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #58 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: 2501
  • Country: us
  • Yes, I do this for a living
Re: Beginner FPGA dev board
« Reply #59 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 #60 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: 700
  • Country: no
  • Musician, developer and EE hobbyist
    • alexanderbrevig.com
Re: Beginner FPGA dev board
« Reply #61 on: December 08, 2015, 09:56:20 am »
 

Offline nowlan

  • Frequent Contributor
  • **
  • Posts: 649
  • Country: au
Re: Beginner FPGA dev board
« Reply #62 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: 346
  • Country: us
Re: Beginner FPGA dev board
« Reply #63 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: 2571
  • Country: gb
Re: Beginner FPGA dev board
« Reply #64 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: 2571
  • Country: gb
Re: Beginner FPGA dev board
« Reply #65 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: 1408
  • Country: us
Re: Beginner FPGA dev board
« Reply #66 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: 5550
  • Country: us
Re: Beginner FPGA dev board
« Reply #67 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: 2571
  • Country: gb
Re: Beginner FPGA dev board
« Reply #68 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: 1408
  • Country: us
Re: Beginner FPGA dev board
« Reply #69 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: 2571
  • Country: gb
Re: Beginner FPGA dev board
« Reply #70 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 »
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Beginner FPGA dev board
« Reply #71 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.
 

Offline MagicSmoker

  • Super Contributor
  • ***
  • Posts: 1408
  • Country: us
Re: Beginner FPGA dev board
« Reply #72 on: December 17, 2015, 10:39:21 am »
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 guess there is some truth to that old cliche about America and Britain being two countries separated by a common language... I said that the problem was NOT with my credit card issuer (they stated they never received a charge to decline, actually). Aliexpress sent me an email (the body of which is reprinted below) which was reminiscent of "Brazil" (the movie) or "Catch-22" (the book):

Quote
Thank you for shopping on AliExpress !

We are sorry to inform you that we have to cancel your order for security reasons. To make sure your transaction is secure, please provide us with documentation for further verification.

When we receive your documents, we will verify them within 3 business days. If the documents are valid, you can reorder on Aliexpress.

We apologize for any inconvenience, and thank you for your patience and understanding.

As you may note without me even prompting, nowhere does it say what "documentation" is necessary "for further verification." Furthermore, there is a line at the bottom of the email that says it was automatically generated and that replies to it will be ignored. THAT is why I am unlikely to place another order with them anytime soon. An FPGA development board is work related, and the way I see it, if I spend 30 minutes screwing around with Aliexpress (or writing posts about it here... ahem) then I just blew whatever money I theoretically saved vs. buying a legit board and USB Blaster from DigiKey, etc.

You picking up what I'm putting down now, compadre?
« Last Edit: December 17, 2015, 10:42:48 am by MagicSmoker »
 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
Re: Beginner FPGA dev board
« Reply #73 on: December 17, 2015, 03:36:26 pm »
Did you happen to apply for an AliPay account? I seem to recall requiring documentation for that, but it shouldn't be needed. A straight credit card transaction should work just fine. I'm sure if you were ordering from Nigeria things would be different, but the USA should be just as easy as the UK for VISA or Mastercard. AMEX is another thing entirely if thats what you used.  :-//

Oh, Brazil is one of my favourite movies  :-+ You wouldn't be a Mr Tuttle, sorry Buttle by chance?  ;)
« Last Edit: December 17, 2015, 03:38:14 pm by Macbeth »
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Beginner FPGA dev board
« Reply #74 on: December 17, 2015, 06:59:50 pm »
I've bought quite a lot on Ali ,and never had a problem with my Visa Card.
I even feel i'm better protected there than on *bay/*Pal.

They don't release the money to the seller until you have confirmed that you have received your goods.

Just don't miss your "last protection" date, before you make a dispute/claim.

I have made 3 disputes, and have gotten my money back every time wo. any hazzle.


/Bingo

Ps:
The most annoying thing, is that they are often shipping via registered mail , and you have to go to the post office to pick it up.
Then again, it might even be an advantage getting it via registered mail or ....

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf