feedback on user experience

peepo

on the positive side:
I like the '7 league boots' approach used by hamster and logi.
ie assumption user will tie ends together.
however I remain to be convinced this will generate growth and community,
even vaguely similar to Raspberry Pi or BBC microbit, one might desire.

and whilst the pre-built eduboard examples are great,
trying to use them oneself could be made very much easier.
deconstructing megabytes of uncommented code,
some of which does not build and run,
will not be to everyone's taste!!!
this is in my view the number one priority to build growth and community for beginners.

Clocks, memory etc...
LogiCORE is barely mentioned and needs examples and an easy to understand overall introduction with broad description
this is a complete deal breaker, understanding PLL etc is crucial even to a rank beginner.
similarly having provided SDRAM let's have a project, rationale and guide...

8 LEDs seems to be standard, why not provide them?
cf Pong book
if you are not going to, then be sure to give some excellent debugging advice.
'beef' & 'dead' really is not sufficient....

I now need more cookbook style examples allowing one to understand what is available and why one might want to use it.
ie: LogiCORE mentioned, also
wishbone gives access to opencores, but review of opencores are not altogether enthusiastic about ease of use,
and no examples are given afaict...

I'm extremely pleased to have chosen LogiPi, which has been an excellent learning experience for me. 8/10
however I believe that much of the potential remains opaque to me at present 2/10
community almost latent hence 2/10
ease of use 2/10
Logi support 8/10
I also appreciate the significant work involved in bringing documentation and product to its present state.

mjones

Hi @peepo

Thank you for your thorough feedback it is very useful to have this.  All, well received.  We are in a very strange space in between FPGA users and embedded users and not strongly with an emphasis more on FPGA users who can use the LOGI boards with BBB/RPi.  It is hard to figure out where to focus our attention in terms of audience and it may be a bit too broad at the moment.   I consider our tools, examples, designs as very immature relative to where we want to end up.  I see a great amount of opportunity to keep moving in a direction that best suits the largest number of users and we hope to moving in that direction.  With your feedback we hope that this will be the case.  

Unfortunately we have been in a bit of a lull, which E14 running out of boards in January and not having finalized VFX and E14 next steps/engagements on producing more boards.  The outcome is that we are now only finishing up FCC/CE approval and MFG of the next round of LOGI boards.  We hope that our the flow and availability of LOGI boards will be steady from here on out which we hope to bring in a more regular stream of users to the forums (mostly just support at the moment).  Again I think we are in a very niche space between Rpi/BBB and FPGA.  Not many users are capable in both areas and those strong in one are not strong in the other, which makes the current LOGI pi/bone a large potential challenge.  We certainly hope to continue improvement of the tools and stacks that we offer to make make the user experience easier.

“Clocks, memory etc...

LogiCORE is barely mentioned and needs examples and an easy to understand overall introduction with broad description

this is a complete deal breaker, understanding PLL etc is crucial even to a rank beginner.

similarly having provided SDRAM let's have a project, rationale and guide…”  

These are indeed good points to address and hope to get to these in time.  As with FPGA technology the aligned peripheral technology is generally very complex.  Xilinx and Altera have done a great amount of work using application notes, guides and tutorial on their own “IP” cores, which we should certainly have a “basics” of using xilinx cores with LOGI boards, but leave the details and Xilinx’s own available documentation.  As well Micron and other SDRAM vendors have made a great deal of documentation available for the nitty gritty details, but we should certainly create our own general guides on tieing in the use of SDRAM with the LOGI boards.  We hope to get to these items when we can.  

8 LEDs seems to be standard, why not provide them?

cf Pong book

if you are not going to, then be sure to give some excellent debugging advice.

'beef' & 'dead' really is not sufficient....

We would have loved to have been able to add 8 LEDs or every, but where we are using a limited pin count FPGA (TQFP144 - lowest cost) we had to make sacrifices in how many we were able to put onboard.  We have spent a great deal of time trying to scrape up every pin for usage in the many different modes of operation that the LOGI boards are used in.  In the end we hope t we have made a good balance, between usability and the use for getting up to speed on the education front.  8 LEDs is perfect for education and learning but would rarely all be used or needed in practical applications.  We have created a “wrapper” which you can use the 4X SSEG to support 8 or 16 emulated LEDs.  This is potentially a something we could write a wiki page on if it is of use to others.  

Anyhow, we certainly want to address all of the above and hope to do so as things continue to grow.  We hope to get through our current MFG/availability lull and release some new products later this year, which we hope will bring in more FPGA/embedded users.

Anyhow for now please keep giving us feedback and what you would like to see!

Cheers! 

ronyoung1

I would like to second Peepo's feedback. One area that I am very interested in is using the fpga to develop (for lack of a better term) "custom computer/device instructions".

Unfortunately, I don't have large chunks of time to play and figure out how things work. Since I am a software person, this presents a large learning curve before I can get something useful.

What would really be ideal for me would be to have a complete example that incorporates a soft core (either a simple toy design or something from opencores.org). In addition to the fpga side, have a "server side" that uses the wishbone bus to send/receive "block" data.

For a toy design, maybe a simple SIMD (single instruction multiple data) co-processor:

use the wishbone bus to load operand vector arguments and execute simple instructions

that can return either a  vector or scalar result. Maybe vector add/multiply/etc and scalar

(max/min/sum/average).

<br>

If an opencores.org core is use, an example that uses the wishbone bus to do block (disk) and serial (character) terminal I/O would do the trick. This would allow you to and simple

extensions to a known working example without a big first step...

<br> 

Another thought (I only wish I knew enough to do it myself) is to implement as an example the CPU presented in the book "Building a Modern Computer from First Principles" by Nisan and Schocken (http://nand2tetris.org)

<br>

thanks...