Summer of FPGAs -- OrangeCrab Dev Bd

Table of contents



{tabbedtable} Tab LabelTab Content

OrangeCrab is an electronics development board. It is FPGA based, featuring an ECP5 from Lattice. The board follows the slim feather board specification from Adafruit. The FPGA is compatible with the opensource toolchain and is perfect for experimenting with RISC-V and other softcore SoCs.

orangecrab dev board


  • Lattice ECP5 FPGA csfBGA285 package(LFE5U-25F-8MG285C)
  • On-board DDR3L memory
  • Direct USB-C connection to the FPGA
  • FPGA based Full-speed (12Mbit) USB
  • 128Mbit QSPI FLASH Memory
  • MicroSD socket
  • High efficiency DCDC for main supplies, battery charger (100mA), lipo battery connector (PH type)
  • 48MHz on-board oscillator
  • User I/O(1x button, 1x RGB LED, 20x I/O on 0.1" headers, 6x analogue compatible)
  • Dimensions: 22.86mm x 50.8mm (0.9" x 2.0")


Additional Information

Important Dates

Enrollment Begin: Jun 25 2021

Enrollment Ends: July 26 2021

RoadTesters Selected: July 28 2021

Product Shipped: July 30 2021

RoadTesting Begins: Aug 5 2021

Reminder/Update Email: Sept 5 2021

Submit Reviews By: Oct 5 2021

*The element14 RoadTest Staff will send this reminder/update email.

**If a RoadTester is unable to meet the deadline, please notify the RoadTest Program Lead, , as soon as possible before the deadline.


How to locate the official RoadTest review form:  How To Locate the Official RoadTest Review Form (duplicate)


Terms and Conditions

OrangeCrab Dev Bd– RoadTest

Terms and Conditions

These are the terms and conditions which govern the Orange Crab Dev Bd RoadTest contest. This Contest requires participants to submit an application indicating their previous experience with this type of equipment/component, information on what they would do to test the equipment/component, and the applicant’s desire to post a thorough review of their experience with images, photos, or other supplemental materials. Participants will be required to meet the Conditions for Participation.  The winners of this RoadTest will receive the item(s) listed below. RoadTest Reviews are due no later than 60 days after the receipt of the item(s). No other prizes are offered.

The Principal terms of the Competition:

The following words and phrases are used in these terms and conditions and have the meanings given to them below.


Key dates:

Applications Close: midnight (GMT) on July 26 2021

Announcement of Winner (estimated): July 29  2021

Prize: MPS Four-Channel Output Power Module EVM

Additional Prizes: none

Competition Site:

Site or element14 Community:

Judges: members of the element14 community team chosen at the Organiser’s discretion.

Judging Criteria, All of the following which will have equal weighting:

· Demonstrated competence with the technologies including links or descriptions of past projects

· Qualifications as indicated by current job role and/or schooling/vocational training;

· A thorough description of how the prize would be tested;

· Likelihood that the Applicant will blog about the prize and provide a review on;

· Originality;

· Innovation.

Organiser: Premier Farnell plc (registered in England and Wales under company number 876412) whose registered office is at Farnell House, Forge Lane, Leeds, UK

Conditions for Qualification: in addition to meeting the requirements of these terms, all persons applying to take part in the Contest (each one an Applicant) must:

· Provide a RoadTest application describing what he/she would do if awarded the Prize including similar previous projects, product experience and qualifications

Terms: these terms and conditions which govern the Competition and to which the Organiser reserves the right to make changes from time to time and the latest version of these Terms from time to time will be posted to the Site.

  1. Eligibility
  2. Applications:
  3. Selecting Winners:
  4. Liability:
  5. General:

1.1 Save as set out in these Terms, the Contest is open to any natural or legal person, firm or company or group of natural persons or unincorporated body.

1.2 All Applicants must be aged at least 18 at the time of their application.

1.3 Applicants must not enter the RoadTest if doing so or taking part may:

1.3.1 cause the Organiser and/or themselves to be in breach of any agreement (including but not limited to any contract of employment) to which they are a party or in breach of any law, regulation or rule having the force of law to which the Organiser or the Applicant may be subject or any policy of the Organiser or the Sponsor;

1.3.2 Require the Organiser to obtain any licence, authorisation or permission to deal with the Applicant; or

1.3.3 Be in breach of any policy or practice of their employer. Some employers prohibit or restrict their employees from taking part in competitions such as these or receiving prizes under them and the Organiser respects those policies and practices.

The Organiser reserves the right to disqualify any Application made in breach of these Terms and to reject any Application which it reasonably believes may be or become in breach. The Organiser reserves the right to require evidence in such form as the Organiser may reasonably require of any Applicant’s compliance with any of these Terms and to disqualify any Applicant or Participant who cannot provide such evidence reasonably promptly.

1.4 Multiple applications are not permitted.

1.5 Applications may not be submitted by an agent whether acting on behalf of an undisclosed principal or otherwise.

1.6 The Contest is NOT open to:

1.6.1 Any person or entity who is a resident or national of any country which is subject to sanctions, embargoes or national trade restrictions of the United States of America, the European Union or the United Kingdom;

1.6.2 Any employee, director, member, shareholder (as appropriate) or any of their direct families (parents, siblings, spouse, partner, children) (“Direct Families”) of the Organiser and Sponsors; or

2.1 Each Applicant must fully complete and submit a RoadTest Application by the Application Close.

2.2 By submitting a Registration Form, each Applicant:

2.2.1 Authorises the Organiser to use his or her personal data (as defined in the Data Protection Act 1998) for the purposes of running and promoting the RoadTest;

2.2.2 Authorises the Organizer to copy, reproduce and publish their application should they be accepted as a Participant;

2.2.3 Will be deemed to have read, accepted and agree to be bound by these Terms. Applicants are advised to print and keep safe these Terms;

2.2.4 Authorises the Organiser to copy, reproduce and use the Application and/or Review for the purposes of the RoadTest and as otherwise contemplated by these Terms. The Organiser will not be responsible for any inaccuracy, error or omission contained in any reproduction or use of the Project Blogs.

2.2.5 Licenses the Organiser to use the intellectual property in the Project (IP) for the purposes of this Contest. As between the Applicant and the Organiser the IP remains owned by the Applicant.

2.2.6 Grants the Organiser the right to use his or her likeness, photographs, logos, trademarks, audio or video recordings without restriction for the purposes of Contest or the promotion of it or the Site;

2.2.7 Agrees to participate positively in all publicity surrounding the Contest;

2.2.8 Agrees to be responsible for all expenses and costs incurred by him or her in preparing for, entering and participating in the Contest (save for any expenses expressly agreed by the Organiser to be borne by it in these Terms);

2.2.9 Confirms that he or she owns all IP used in his or her application or Project or Blogs and indemnifies the Organiser from any claim by a third party that use of any material provided by an Applicant to the Organiser infringes the intellectual property rights of any third party;

2.2.10 Agrees not to act in any way or fail to act in any way or be associated with any cause or group which would have a negative impact on the reputation of the Organiser and/or the RoadTest.

2.3 All applications submitted to this RoadTest must meet the following criteria:

2.3.1 Applicants must be the author, creator and owner of the proposed review idea. Applicants must not submit someone else’s idea;

2.3.2 The proposed application must be reasonably achievable by the within the time constraints of the Contest;

2.3.3 Applications must not include or propose any of the following, the inclusion of which shall render any proposed application ineligible:

(a) Applications which relate to socially taboo topics, such as illicit drug use or sexual gratification;

(b) Applications that are or could reasonably be considered to be illegal, immoral, discriminatory or offensive as determined by the Organiser;

(c) Applications in relation to them which if accepted would infringe or breach any of the policies or terms of access or use of the Site.

2.4 No Application may contain any of the hazardous substances identified by Article 4 of Directive 2002/95/EC of the European Parliament on the Restrictions on the Use of Substances in Electronic and Electrical Equipment ("the Directive") or the use of such hazardous substances in the in any such Project must not exceed the maximum concentration values set out in the Directive.

3.1 Winners will be selected by the Organiser on the basis of the quality of his or her application and its adherence to these Terms.

3.2 The total number of Winners selected will be at least the minimum number set out above but the actual number is at the sole discretion of the Organizer and/or the Sponsor, if applicable.

3.3 The Organiser will use all reasonable efforts to announce the Winners via an update to the RoadTest page by the date listed above.

3.4 Winners agree to take part in all publicity which the Organiser or the Sponsor wishes to use to promote the RoadTest, the Products featured or other Contests with which the Organiser may be connected from time to time.

3.5 Details of the Winners may also be published in the media.

3.6 Winners are responsible for all applicable taxes, duties or other charges payable in relation to any prize.


4.1 The Organiser hereby excludes all and any Liability arising out of the Contest or the acceptance, use, quality, condition, suitability or performance of any Prize, even where that Liability may arise from the Organiser’s negligence.

4.2 Nothing in these Terms will affect any Liability of the Organiser for death or personal injury arising from its negligence, for breach of Part II of the Consumer Protection Act 1987 (in the event that any entrant is entitled to claim rights under the Consumer Protection Act 1987) or for any matter in relation to which it would be illegal for the Organiser to exclude or to attempt to exclude its Liability.

4.3 Subject to 4.2, neither the Organiser, any parent company nor any subsidiary of the Organiser or such parent company or any of their directors, officers and employees (together referred to in these terms and the ‘Associates’) makes any guarantee, warranty or representation of any kind, express or implied, with respect to this Competition or the Prizes potentially available under it. Neither the Organiser nor any of its Associates shall be responsible for any Liability that may arise out of or in connection with person’s participation in this Competition, the claiming, redemption or value of any prizes under it, the use or enjoyment of such prizes or any events or circumstances arising out of or in connection with any of them. Any implied warranties of condition, merchantability or suitability or fitness for purpose of any of them are hereby expressly excluded. Wherever used in these Terms, ‘Liability’ shall mean any and all costs, expenses, claims, damages, actions, proceedings, demands, losses and other liabilities (including legal fees and costs on a full indemnity basis) arising directly or indirectly out of or in connection with the matter concerned.

5.1 The RoadTest is organised and sponsored by the Organiser. The Organiser reserves the right to delegate all or any of its powers, rights and obligations arising in relation to the RoadTest to any Associate and certain such rights and powers are assumed by the Organiser on behalf of itself and each Associate. Reference to “Organiser” shall be deemed to include reference to each Associate.

5.2 The RoadTest may be terminated at any time if there are, in the sole opinion of the Organiser, an insufficient number of entries, or if the Applications are not of an appropriate standard for a competition of this nature. The Organiser has the right to cancel or suspend the RoadTest at any time due to circumstances outside its reasonable control.

5.3 The Organiser shall have the sole discretion to disqualify (without correspondence or right of appeal) any Applicant it considers to be adversely affecting the process or the operation of the RoadTest or to be in breach of these Terms or to be acting in a disruptive manner or with intent to annoy, abuse, threaten or harass any other Applicant or Participant.

5.4 The Organiser has the right to amend or add to these Terms from time to time. Revised Terms and Conditions will be posted on the Contest Site and it is a condition of entry to the RoadTest that Applicants agree to comply with these Terms and, if appropriate, such Terms as amended from time to time.

5.5 Headings are for convenience only and do not affect the interpretation or construction of these Terms and Conditions.

5.6 These Terms and the operation of the Contest shall be governed by and construed in accordance with English Law and any claim or matter arising under these Terms shall be subject to the exclusive jurisdiction of the English courts.

Comment List
  • Looking for some E14 Community insight on this RoadTest review.


    What is your opinion on an individual with NO FPGA experience beginning their knowledge curve starting point with this product?


    When I say NO experience I mean, they can't even spell FGPA, FPAG....FPGA.

  • If I were part of the OrangeCrab dev team I'd actually be really keen to see what a newcomer made of this board - its the ideal testing ground to make sure that all documentation is clear and concise enough to allow them to get up and running. A newcomer without any prior knowledge is a great way of finding any issues that need correcting. The documentation needs to be simple enough to get them running an interesting demo as soon as possible without too much extra information and then to expand from there.


    The OrangeCrab is a dev board and IMO could easily have a great uptake by the maker and bespoke project builder or indeed academic institutes in the same way that RPi, Arduino, Beagleboard etc are supported. Whereas a product manufacturer may use such a board for initial prototyping but would soon likely migrate to using the Lattice ECP5 device directly on their own PCB design.

  • Is FPGA a vendor agnostic implementation or is their tasks common to getting FPGA to work?


    I'm looking for a general (if such a beast exists) FPGA implementation and not one specific vendor. I hoping to pickup a broader scope for implementation and then understand yes this vendor does what I want.

  • Is FPGA a vendor agnostic implementation or is their tasks common to getting FPGA to work?


    I'm looking for a general (if such a beast exists) FPGA implementation and not one specific vendor. I hoping to pickup a broader scope for implementation and then understand yes this vendor does what I want.

  • I'm no expert is quite confusing. I'll try and explain from what I've learned so far.


    Configuring the FPGA firmware is (1) partly vendor specific and (2) partly common (3) and new push towards agnostic. That isn't probably very helpful !


    1.     Vendor Specific. For example Xilinx manufacturer a huge range of FPGA devices and their IDE (Integrated Design Environment) is called Vivado and I believe it is specific to their devices. That said many development board manufacturers also use the Xilinx devices with a handful of other chips, Digilent is one such manufacturer that often incorporates Xilinx FPGA devices on their boards. And these Digilent boards are easily setup from the Xilinx IDE. Using the Vivado IDE is therefore bound to developing on the Xilinx devices. In the same way I believe Lattice or Intel will provide their own IDE which will be developed to maximise potential of their devices and support their loyal customer base. So at this point the choice of vendor requires you to learn and utilise their development tools.


    2.     Common. Within those development tools there is underlying principles to coding the firmware within the FPGA, these Hardware Description Languages (HDL) appear similar to a standard computer program. The biggest difference is how they are implemented; whilst a computer (single thread) runs sequentially line by line the HDL allow blocks of code to be run concurrently i.e. clock cycles affect change simultaneously in several parts of the device. There are two main HDL: Verilog and VHDL. Without going too deep, lets just say they are similar. Learning either HDL allows bespoke blocks to be built in the higher level vendor specific IDE. Therefore learning a HDL can be useful regardless of what vendor you will choose.


    3.     Opensource/Agnostic. And then there are products like this OrangeCrab which I know nothing about yet but see they tout an open source toolchain. I'm interested to see what that software entails, indeed its free so I'll add it to my list of things to explore. My reservation without knowing more is, given all the manufacturers of FPGA and the vast lists of devices each make, it would be an onerous task to ensure any opensource software can optimally configure each device. I currently use the Xilinx IDE software and it is essentially free, some licensed versions include extra IP (Intellectual Property) which is essentially a higher level building block with inputs and output connections. As this Xilinx IDE is quite a beast of a program I have stuck with it to better learn the finer points which as a hobbyist dabbling in my sparetime I would otherwise soon forget. I'm sure people in the career of programming FPGA could learn several IDE and use different manufacturers more easily. There are also a few FPGA tools in Linux opensource - I have no idea how easy they are to use or how the generated code is programmed into the end board/device.


    Given your desire to stay agnostic to any vendor the Opensource Toolchain mentioned on this product could be your way ahead to see, but I guess it depends if other vendors also support it longer term. My suggestion to you would be to apply for this OrangeCrab roadtest and find out/blog about it. One thing you may like to check before hand is how to install the toolsets they mention: I had a brief look and it seems quite complicated so I wouldn't want to encourage you to apply and they see you struggled with the setup image. Your application would also look really good IMO if you had bothered to download/install and investigate the toolset.


    I mentioned the Xilinx Vivado software being free. You may well pickup a dev board roadtest in the future - the Digilent Arty range are quite easy to get going with. Another point to note though is that Vivado is very processor hungry. I really struggled on my old i5 processor with builds taking hours, my current i7 isn't too bad image


    Let me know if I can try and explain anything else. Hopefully I haven't confused you with the above !

  • Hi Rod,


    That's a very good, and detailed explanation! It is content that should go into a FPGA FAQ one day maybe, since many people could benefit from that.


    I looked to see what I could find (I found some diagrams created before) in the way of an explanation of the guts of the FPGA and the toolchain type of perspective, i.e. bottom-up, to see the workflow and what can be done vendor-specific and what can be done open-source, so perhaps this too can help combined with Rod's explanation. I'm no expert either, currently just partially aware of a few bits of info here and there:


    An FPGA is as the acronym suggests, an array of logic gates that can be connected as desired. It turns out that to make things fast, the gates should have some structure to them. Therefore, an FPGA can inside contain the sort of stuff shown in the diagram below; the left side labelled Slice (also often referred to as a block), if you look closely, contains the lowest level elements, things like AND gates, look-up tables and flip-flops. There can be thousands of these blocks inside an FPGA, and the aim of the game is to configure or link up the insides of each of these blocks, and interconnect each block to overall make the FPGA do what you want.


    The interconnections between blocks is called Routing. To keep things efficient there could be RAM on-board for any use desired too. Ultimately any signals can be routed out to general purpose I/O pins.




    To make all the connections inside the slice (let’s call is a block) and between blocks, you’d have to first create a design somehow. That design could be a schematic containing the blocks and the interconnections, drawn graphically, but it gets complex to manage and design.


    Another method is to write text in a language that software can convert into the interconnections. As Rod says, the difference between that and a computer program is what it implements. In the case of FPGAs, the language is a way to describe your intent to make the logic connections, so it’s called a ‘Hardware Description Language’ instead of a computer ‘Programming Language’. A computer program resolves down to instructions for an engine (CPU) so it's not the same thing as instructions to wire logic gates together. Wiring logic gates can make things run in Parallel as Rod says, whereas a CPU is normally fairly sequential.


    Rod mentions that a couple of popular HDLs are VHDL and Verilog.

    Here’s an example of generating PWM in Verilog:


    The Verilog content above can be mostly understandable if you read through it even without any Verilog knowledge, it can be seen that it is implemented to accept a clock (much like any CPU running a program would require a clock, although that's where the similarity ends in this example), and there are pins to input the binary duty cycle value, and there is a single pin to output the PWM based on that duty cycle value and a count of the clock pulses.


    With a computer programming language, a compiler and assembler are used to translate computer code into low-level instructions. With HDL, an FPGA toolchain is used to "synthesize" the HDL into a design that uses the blocks in the FPGA. Below is what that PWM example looks like once converted into connections inside and between blocks. You can see that I've tried to draw boxes around different parts of it, so you can see how a binary comparator, registers and adder were created by the FPGA toolchain, to perform the PWM work. Obviously, the schematic is a huge mess, so it is not something that is normally viewed by the user of the FPGA toolchain. But by looking at it, you can appreciate the work that goes on inside the tool. You can also appreciate that if the HDL was written wrong or suboptimally, it could be that the synthesis tool will generate something different to what was expected, and a few lines of HDL might unexpectedly cause hundreds of blocks to be synthesized together accidentally.  As a result, you're not truly free to type anything and expect it to synthesize correctly and run. Really you're trying to type lines of HDL in a way that the toolchain will recognise, and straying too far off that has the risks mentioned if the FPGA toolchain infers something which you didn't mean.


    Just to reiterate, the schematic diagram above is just to understand what is going on with the toolchain's work. It is not something to be able to understand. All that complexity is removed from view, because the developer creates the much simpler Verilog content (in this example).


    The remainder of the FPGA toolchain is responsible for finding the best way to map the blocks onto the real estate on the FPGA chip, connect up the links in the best way to implement that schematic above, to run at the desired speeds, and bring out the inputs/outputs to real pins on the FPGA so it can be wired onto a circuit board. As a result, although the HDL that you write can be fairly agnostic, since it needs to map to connections in a chip with blocks arranged in a vendor-specific way with logic gates arranged inside each block in a vendor-specific way too, then the toolchain needs to be aware of the vendor-specific stuff once you get to the part of your workflow where you want to start placing bits of the design into different areas of real-estate on the chip, and routing the interconnections inside the chip.


    Incidentally the toolchain also allows you to create stimulus signals and feed it into the design, so you can confirm outputs behave as they are supposed to. Such test code is often written in a HDL too, but it doesn't need to be. Also sometimes people use different vendor tools for that (or can be open source).


    In general regarding open source FPGA toolchain, this is possible but the only one I'm aware of only supports Verilog, not VHDL. Also, it only supports certain FPGAs, because as mentioned it is manufacturer-specific what file format is required to create the connections inside and between blocks, and in fact the blocks are different between different manufacturers anyway. Also in practice it's not as efficient as manufacturer-specific toolchains, because manufacturers have invested a lot of time and money on that, and open source still needs to catch up in that respect, but that's not to say the open source output is not usable, it's just that it may consume more resources on the chip, or speed may be impacted.


    Also, just to mention, although the discussion here referred to two HDLs, there are others, and also there might be building block type environments out there too, but I'm just speculating, it's for further investigation. For instance I think Arduino offered ready-made bitfiles for making FPGAs do certain tasks maybe. Anyway that's more uncommon/unusual for a 'normal' FPGA workflow perhaps.


    I may have got some details wrong, but hopefully from a birds-eye-view it is mostly close enough. For more information about FPGAs, there are short PDFs for different topics related to FPGAs, they are uni course notes teaching FPGA and Verilog.


    Also there are general (not FPGA specific) digital electronics  lecture note PDFs here.


    Also,  is working with FPGA devices too and his FPGA blogs provide lots of useful input to beginners to follow, because even if it relates to a different device (and different language - Jan is using VHDL) the concepts are the same and eventually reading from different perspectives starts making sense. When I started, I made no sense of FPGAs from a single source, but then pieces started falling together, and it accelerates, along with a bit of hands-on of course, so it's nice to see these FPGA boards being offered for RoadTest. The Lattice toolchain installation may need less computer resources than Vivado too, which is good. From limited experimenting, Lattice toolchain looked a lot easier to get into than Vivado. But as mentioned in the RoadTest, the open source toolchain is supported for that FPGA too.

  • When you don't know, what you don't know, it is difficult to ask about what you don't know. I started with no knowing how to spell FPGA:)


    I struggled with posting my question. I have tried to follow some FPGA posts and usually get, lost simply because I have no frame of reference to hang the knowledge. Like putting stuco on a wall, without the wire mesh, the stuco has nothing to support it. You can apply some stuco without the wire mesh but you soon discover, the mesh give the framework that supports the material.


    I have an extensive technical background. I have some stuco wire in place but there are large gap areas. My career began when tubes were still in use and recently ended after a shorter than I would have likes IT Security stint.


    You explanation is spot on. You filled in some don't knows. I have a reluctance to take on this RoadTest. I typically see the end when I approach a RoadTest. I have the start and then assemble the pieces to reach the end. I have discovered the end sometimes moves, that is OK.


    For this RoadTest. What is the end? I have a working FPGA? What does that mean. I just read there are PFGA's in the SDR for this RoadTest. Digilent 1x1 USB Software-Defined Radio Platform   I'm not sure what that means. I will read this again after a few drinks and maybe I will get some courage:)

  • "...I have no frame of reference to hang the knowledge. Like putting stuco on a wall, without the wire mesh, the stuco has nothing to support it..."


    Clive Maxfield's FPGA book may be of interest. It is a bit dated now (2004) but it would probably help fill in some of the gaps:

    (Not only will you be able to spell FPGA, you will likely be able to pronounce it as well image)


    There is a preview of it on Google Books if you want to flip through a few pages to see if it gives you any of the 'wire mesh' you are looking for.


    "...What is the end? I have a working FPGA? What does that mean..."


    Probably that you now have a rather expensive blinking LED in front of you, and you are now wondering where the last four weeks went... image

  • I have been doing some follow-up on the references you provided. I found some knowledge that shook my foundation. Well let's just say it caused it to tremor.


    How prevalent is the change in Logic Symbols? IEEE Standard 91-1984 Explanation of Logic Symbols, "The International Electrotechnical Commission (IEC) has been developing a very powerful symbolic language that can show the relationship of each input of a digital logic circuit  to each output without showing explicitly the internal logic." I have a good comprehension of logic symbols. I now see why some of the FPGA documentation has been confusing. This new nomenclature is used in FPGA schematics and since I wasn't aware of it, I was immediately I'm lost.


    I found it difficult to find a comprehensive guide to these logic symbols. My impression is its research and academia study leaving the ground truth. My logic knowledge is hard earned. Rather shakes my confidence when it suggested we won't use that anymore. I had to give up the symbols for vacuum tubes when they passed away. Now the beautiful AND gate is gone as well. I don't think that memory is writable anymore, it's atrophied. 

  • Thank you. And wow...I need to bookmark all the info you have also provided for as that is a great introduction.

  • Very well said and I think most of us have also been in your situation. I often find I'm unable to articulate a technical issue but as the discussions start then snippets of info fall into place. Your stucco analogy is a good one that I can understand having failed myself in similar home improvements without suitable support mesh.


    I'm not aware of the term PFGA and will have to look through the roadtests you link to see. Maybe it was a typo by that roadtester?


    If you have doubts maybe another approach rather than 'throw yourself into the roadtest spotlight' with the pressure to deliver in the mandated period is to buy a cheap FPGA development board. Something like the Digilent Cmod S7: Breadboardable Spartan-7 FPGA Module or Lattice Semiconductor: ICE40HX1K-STICK-EVN iCEstick Evaluation Kit would be low cost starts.


    And then you mention, to what ends? I guess you would either learn some of the processes and (as   mentions ) have an expensive and complex flashing LED and then stop or perhaps you have projects that would benefit from some fast bespoke logic implementation. An example is perhaps you've developed a AES-128 algorithm in Python or C that needs to run on a computer and therefore thakes time. You could implement the same directly in logic and have it execute far quicker.

  • If you go for a Xilinx one, check if it's covered by the free WebPack license (for either ISE or Vivado IDE)