I believe devices are loaded into HDL Coder based on the devices supported by the latest tool version MathWorks was able to test against, so they will inevitably lag behind the latest devices supported by a third-party tool. However, you can always change the device manually in the generated project file if needed for timing analysis.
That said, there are a number of different ways the device in the HDL Workflow Advisor can be used, and it may not be important to make the distinction between ES and production silicon in every case.
- For code generation, I don't know of any difference in the generated VHDL or Verilog based on the specific device. It's important to select the right tool chain so constraint files, synthesis attributes, and a project file can be created for the correct tool. But I don't think the device is used except to configure the generated project file, and you can edit that manually (or with a script) after the project file is created with HDL Coder if you wish.
- If you want to validate timing directly from the HDL Workflow Advisor, production devices will generally have better timing than ES devices (at least in my experience), and thus it will be easier to obtain compliance of your design against production silicon. But you can get a preliminary idea with an ES device in many cases, and if the ES device meets timing, you should be okay on production silicon as well. (Again, that's just my experience.) Anyway, if you want to validate timing on the correct device, you can generate the project in HDL Coder, change the part in the tool, and run timing analysis from the tool.
- If you want to generate a bitstream, you'll have to do some portion of that directly in the third-party tool since the generic workflow doesn't perform bitstream generation. So while you're making preparations for bitstream generation, you can easily change the device as part of that preparation process.
